Эдуард, когда в компанию, в котороя я работала набрали много новых аналитиков (наверное по опыту работы их можно считать теми же студентами) ПМ подошла к вопросу контроля так:
была составлена табличка с артефактами и сроками их сдачи, была введена шкала оценки готовности артефактов, раз в неделю проводилось небольшое собрание где каждая группа отчитывалась об успехах. Старший группы (более опытный аналитик, думаю что в твоем случае это  преподаватель) следил за соответствием плана факту и качеством документов.

Может тебе такая схема немного поможет?

Может тебе такая схема немного поможет?

Ирочка, спасибо. Примерно такую схему я и использовал, вероятно, в будущем надо будет усилить ее в рамках отчетности. В целом аналитики как раз сработали нормально. Единственно, что они как бы устранились на дальнейших этапах, хотя я их привлекал уже как тестировщиков.

Думаю, нужно будет усилить контроль и лучше распараллелить работы.

Эд, может аналитиков на дальнейших этапах привлекать как заказчиков продукта? Т.е.  сначала аналитики выступают аналитиками, затем, когда фаза анализа закончена, аналитики выступают в качестве заказчика (проверяют соответствие требованиям, удобство работы и т.д.) и отвечают за успешную приемку продукта главный заказчиком (преподавателем).

Не хочешь попробовать схему работ а-ля субподряд: ген подрядчик выполняет анализ, суб подрядчик выполняет разработку, ген подрядчик принимает продукт, заказчик принимает продукт? Мне кажется, что мотивация аналитиков "не самоустраняться" будет повыше.

Ира, да именно этого я добивался, чтобы аналитики стали заказчиками. Но видно где-то дал промашку. Нужно все тщательно расписать и сбалансировать, возможно формализация в данном случае и жесткое регламентирование будет на пользу.

Меня огорчило в это ситуации то, что студенты (особенно программисты) имели большое самомнение и совершенно не хотели прислушиваться к моим советам. А через силу мне не хотелось навязывать свое решение, поскольку в реальной обстановки я бы просто уволил, а тут что сделаешь?

Это достаточно распространенное явление, когда люди со студенческой скамьи приходят на производство и считаю себя полноправными претендентами на должность чуть ли не архитектора. Если всех увольнять, то мало кто останется...

Я полагаю, что с самого начала работы над проектом нужно попытаться объяснить студентам, что эта работа - командная, и делать ее надо не так, как ты сам считаешь нужным, а так, как тебе поставят задачу, иначе результата достичь не получится. И в этом нет ничего постыдного или унизительного для исполнителей: в оркестре никто не импровизирует, каждый ведет свою партию в соответствии с партитурой.

Суворов говорил: "Научись повиноваться, прежде чем повелевать другими". Попробуйте заложить в ваш проект такого рода воспитательный момент, и тогда, возможно, у вас не будет повода для огорчения.

Как мне кажется, очень часто на практике при разработке ПО не уделяется внимание тому, что разработка ПО - это процесс. А между тем, это подчеркнуто даже в названиях методологий, к примеру, в RUP, "P" это process.

Понимаю, что мое замечание может показаться непонятным и постараюсь прояснить его смысл и почему я вообще отвечаю здесь.

Методология процессного управления, помимо многих очевидных действий, таких как выделение команд, ролей, регламентирования процессов и т.п., (применяемых, кстати, многими и при разработке ПО) также требует вовлечения каждого участника в процесс и мотивированности каждого участника на достижение общего конечного результата.

И здесь я вижу большое различие с тем, как обстоят дела с управлением в нашей индустрии разработки ПО. Сразу оговорюсь, что мои рассуждения касаются «традиционной» модели управления, новых методик типа agile я не знаю, может быть там все по-другому.

Как мне представляется, во главу угла при планировании и организации работ при разработке ПО ставится функциональность (начиная с принципов выделения ролей в команде и кончая, в особо продвинутых случаях, списком функций для каждого). Это приводит к тому, что у рядового участника процесса исчезает понимание того, как его действия влияют на общий конечный результат и он просто начинает выполнять свои "функции" - анализировать, писать код, тестировать и т.п. На мой взгляд, проблем тут возникает много. Скажу о том, что мне представляется важным а) такое отношение к делу отупляет, б) страдает процесс в целом.

Так, при процессном управлении, в случае нехватке ресурсов тестировщиков, аналитик мотивированный на достижение общего результата вполне может самостоятельно выполнить работу тестировщика (естественно, согласовав это с PM-ом).
В случае же «функционального» управления аналитику попросту не придет в голову выполнить работу тестировщика. Или же он может «погнушаться» этим, такое встречается даже чаще.

Подчеркну, что основной смысл моей мысли отнюдь не в том, какое управление в организации. И при процессном управлении могут быть неоптимальные процессы. Проблема залегает глубже - в менталитете каждого участника процесса. Если участник процесса а) осознает (сам осознает, а не потому, что приказали), что его (без)действия напрямую влияют на результат, и б) он на этот результат мотивирован – тогда процесс в целом будет выполняться быстрее и качественнее. А если все участники работают «от сих до сих» - процесс будет идти, но медленно и со скрипом. Яркий пример - государственные учреждения, где вся организация базируется на функциональном делении.

Так вот, резюмирую. Эдуард, мне кажется, что в будущем, возможно, стоит уделить внимание тому, чтобы донести до большинства ваших студентов мысль о том, что каждому из них хорошо бы понимать, как галочки в его локальном «To-Do» связаны с конечной галочкой в общем «To-Do». И что действия каждого, способствующие достижению значимого общего результата – это хорошие действия. Даже если их изначально не было в локальном списке задач.

ps. Само-собой, я не призываю к анархии. Планирование, контроль и управление никто не отменял и не отменит. Так что мое высказывание не стоит воспринимать в духе "каждый сам себе PM и начальник".

Я полагаю, что с самого начала работы над проектом нужно попытаться объяснить студентам, что эта работа - командная, и делать ее надо не так, как ты сам считаешь нужным, а так, как тебе поставят задачу, иначе результата достичь не получится. И в этом нет ничего постыдного или унизительного для исполнителей: в оркестре никто не импровизирует, каждый ведет свою партию в соответствии с партитурой.

Спасибо, буду пытаться

Так вот, резюмирую. Эдуард, мне кажется, что в будущем, возможно, стоит уделить внимание тому, чтобы донести до большинства ваших студентов мысль о том, что каждому из них хорошо бы понимать, как галочки в его локальном «To-Do» связаны с конечной галочкой в общем «To-Do». И что действия каждого, способствующие достижению значимого общего результата – это хорошие действия. Даже если их изначально не было в локальном списке задач.

Буду стараться это доносить до студентов. Правда, не совсем ясно каким образом все это обеспечить. Надеюсь, опыт покажет.

Да сегодня проект был представлен заново и качество его улучшилось в разы. Так что стимул оказался действенным. Теперь задача не доводить ситуацию до аврала Хотя в стрессовых ситуациях происходят чудеса:)

Попробую внести свою лепту во все вше сказанное.

В свое время я работал программистом в фирме по разработке ИС. У нас была собранная команда довольно неплохих программистов, но без реального опыта участия в таких проектах. Так вот у нас возникли проблемы довольно похожие на те что описывал Эдуард. Вернее как мне видится что проблемы были схожи. Итак проблема первая заключалась в том что целиком проект себе никто не представлял. Вернее каждый видел примерно по 60-70% проекта. Вторая проблема была во взаимодействии между программистами, т.к. начальник плохо ориентировался в разработке ПО, то времени на обсуждение каждой проблемы мы тратили просто огромное количество. Каждый сам видел ту или иную часть, и считал свое решение лучшим. Мы постарались разбить проект на части, в итоге получилось что каждая часть работает, а когда мы собирали билд проекта то все начинало тихонько осыпаться. Мне не хочется переходить на личности и говорить что в этом виноват тот или иной человек. Я думаю что у студентов Эдуарда возникла очень похожие проблемы.

Какой опыт можно вынести из эксперимента:
1) Студенты какими бы они не были гуру программирования или проектирования не имеют по большей части опыта разработки больших и сложных проектов. Они попросту не знают как происходят процессы проектирования и разработки на практике.

Так вот, резюмирую. Эдуард, мне кажется, что в будущем, возможно, стоит уделить внимание тому, чтобы донести до большинства ваших студентов мысль о том, что каждому из них хорошо бы понимать, как галочки в его локальном «To-Do» связаны с конечной галочкой в общем «To-Do». И что действия каждого, способствующие достижению значимого общего результата – это хорошие действия. Даже если их изначально не было в локальном списке задач.

Вот собственно решение данной проблемы, то есть можно детально расписать роли каждого из участников проекта. Как это донести до студентов мне пока не понятно . Возможно дать каждому описание всех ролей и привести несколько примеров как действия той или иной роли будут отражаться на конкретной роли данного студента.
2) Вытекает из первого после того как все роли прописаны по детальным пунктам, я думаю должно стать ясно какие проблемы и как должен решать студент.

Вот собственно решение данной проблемы, то есть можно детально расписать роли каждого из участников проекта. Как это донести до студентов мне пока не понятно . Возможно дать каждому описание всех ролей и привести несколько примеров как действия той или иной роли будут отражаться на конкретной роли данного студента.

Спасибо, SaTim. Как донести до студентов? Ну это просто. Вот детально расписать роли каждого участника, и определить задачи - это сложнее, вернее, не сложнее, а очень работы много потребует. В принципе - это как сценарий пьесы, где расписаны роли, реплики ролей, временные интервалы, что за чем идет. Вряд ли удастся написать такой сценарий, да, и наверное, в нем нет большого смысла.

Правда, поскольку задача для меня не нова, а детализация ее и способы решения с каждым годом проясняются, думаю можно будет досконально разложить все по полочкам, методически.

Как думаете?

Как думаете?

Думаю будет просто супер!