Вводная:
Команда из десяти разработчиков работала над небольшим приложением в течении нескольких месяцев и не смогла закончить работу в срок.
Вопрос:
Что вы сделаете в первую очередь в качестве нового Менеджера(М) или Senior Developer'а(Д)(с функциями менеджера) на новом большом проекте со старой командой?
Понятно, что ситуация практически патовая: завалили малый - сажают на большой.
Какие будут идеи?

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

Мало ли из-за чего не смогли.
------
Вот и Я об этом думаю.
Только не могу оценить насколько оценка предыдущей разработки должна влиять на принимаемые решения.
Получается так - либо надо тратить довольно много времени на достаточно детальный анализ имевшегося процесса, что само по себе не есть полезно для команды, либо надо отбрасывать практически все, что связано с закрытым проектом, и начинать ставить процесс разработки.
Средины вроде нет - не вижу какую полезную информацию можно извлечь из неполного анализа.
Сам склоняюсь к тому, что нужно просто ставить процесс разработки, распределяя имеющиеся задания и анализируя выдаваемые результаты.

А ты за кого там? ПМ, тим лид, или просто разработчик?

А ты за кого там?
------
Ни за кого. Оцениваю ситуацию на будущее. Учусь, так сказать... :)

Кофе варит :-D

Не , он кофеварку программирует .

Варю. У меня, кстати, получается Экспрессо в домашних условиях. Завидуй!
По озвученной проблеме, как Я понимаю, тебе сказать нечего...

Не , он кофеварку программирует .
-----
Цепь смазывать уже научился? :) Не дрейфь - есть масло в аэрозольном балончике - просто крутишь и прыскаешь... и никакой Жабы...

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

Информации конечно маловато. А что она смогла сделать в срок?
Для начала я бы провел ревизию старого проекта. И постарался бы хорошо запланировать новый по времени. Можно было с каждым разработчиком побеседовать, что бы узнать его мнение.

все зависит о команды.
-----
Хммм... Команда, несомненно, важна... но все же от нее зависит на все... на мой взгляд, при 10 разработчиках, - примерно на 70%, остальное - управление.
в первую очередь необходимо провести анализ причин срыва проекта
необходимо об этих выводах поставить в известность команду
выслушать их версию
-----
вот тут, похоже, и будет основная проблема - анализ придется делать на основе информации от команды - по условиям - новый М или Д. Получается, что надо делать с точностью до наоборот - выслушать, проанализировать, разъяснить. При этом - выслушать и проанализировать - наверняка было сделано внутри команды, если не на командном уровне, то на личном - непременно. Можно ли начинать с разъяснений?
вместе разработать процедуры по исправлению ситуации.
-----
Я бы тоже предпочел, в идеале, реализовать какой-нибудь маленький проект. Причем - реализовать непременно успешно, ознакомившись с проблемами и подыскав приемлемые решения. Но по условиям - большой проект и его надо начинать сразу...
чтобы команда разработчиков не впала в уныние, иначе они с большой вероятностью завалят и следующий проект
если команда постоянная.
-----
Т.е. начать надо с того, что выяснить есть ли Команда, а не 10 отдельных разработчиков? Трудновато будет это с наскоку понять, а времени разбираться - точно не будет. Но команда - да, считается постоянной.
Эээ... еще - ты не делишь рекомендации по М и Д. А, наверное, стоило бы... хотя бы для иллюстрации разницы в подходах М и Д к решению проблем.
Впрочем, одна подзадача, если считать что она обязательна, выявилась:
- необходимо провести анализ причин срыва проекта
- - квалификации не хватает
- - процесс не поставлен
- - сроки нереалистичны
- - требования постоянно менялись
Хотелось бы более-мение точно квалифицировать каждую позицию и перевести в оцениваемую (цифровую) форму. Дополнения к списку - приветствуются.

Информации конечно маловато. А что она смогла сделать в срок?
------
Согласен - информации неприемлемо мало. Ситуация, однако, для нового М или Д - вполне реальная - он именно в ситуации, когда у него нет достаточной информации. Выбирай, что и как будешь оценивать...
Для начала я бы провел ревизию старого проекта.
-----
Сошлюсь на предыдущий пост - хотелось бы квалифицировать ревизию проекта и оценить сроки ее проведения. Последнее - весьма существенно, т.к. 10 х n-месяцев - может быть довольно объемная задача... с нулевой полезностью.
с каждым разработчиком побеседовать, что бы узнать его мнение.
-----
С позиции Д - согласен. Ему так или иначе придется это делать.
С позиции М - не уверен - высказываемое разработчиком мнение отражает его субективную оценку. Насколько оно полезно для М, кроме выпуска пара?

рекомендую прочитать классические книги по программным проектам - "мифический человеко-месяц", и "смертельный марш" - в них приведены основные причины срывов, которые можно примерить под конкретную команду.
по поводу анализа - я может неправильно выразился, но анализ по сообщениям от команды, только одна сторона, для анализа надо принимать во внимание все точки зрения, желательно поговорить с соседними подразделениями, сейлами, может быть клиентами. разъяснения все-таки надо проводить после бесед со всеми, иначе вы можете рассказывать очевидные вещи, которые они сами уже обсуждали, тогда к вам отношение будет, мягко выразиться - странное - "кто-то пришел, и пытается разъяснить очевидные вещи"
ну точки зрения менеджера и девелопера все-таки разные: менеджера в первую очередь интересуют организационные проблемы, приведшие к срыву, в то время как девелопера - технологические.
по поводу причин, можно добавить еще несколько:
- проект не имел достаточно ресурсов для реализации
- проект не лобировался менеджером
- использовалась неправильная методология разработки
- использовались новые, неопробованные технологгии
и т.п.
чаще всего я сталкивался с:
- проблемами малых сроков разработки - продавцы пытались угодить покупателю и т.п.
- проблемами в проектировании системы, что приводило к необходимости изменения архитектуры когда уже прошла большая часть времени, отпущенная на проект
- частое изменение требований, в том числе и оправданное, но без изменения сроков разработки
но лучше всего, быстро прочитать указанные в начале книги - там это все разложено по полочкам, с аргументацией :-) насколько я помню, они были на lib.aldebaran.ru

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

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

Нам же важна общая картина, а она складывается из частностей. Все равно у тебя будет тоже свое субъективное мнение.

Так даже и пар выпустить полезно иначе котел может разнести.

"мифический человеко-месяц"
-----
Я его когда-то читал. Правда тогда еще лишь с позиций разработчика - по типу - Чем прикрыться от М? - и потому много полезного для себя не взял.
которые можно примерить под конкретную команду
-----
Вопрос в том - нужно ли? Как Я уже писал - есть пунтики ЗА, но есть и ПРОТИВ. Хммм... Что бы Я делал в конкретном случае - точно не знаю, но, как говорил выше, склоняюсь к началу проекта без предварительного анализа предыдущего проекта. Только не могу понять - это у меня еще Д или уже М. :) (собственно в этом и вопрос)
пришел, и пытается разъяснить очевидные вещи
-----
У меня обычно проблема не в том, что разъясняются очевидные вещи, а в том, что после разъяснения очевидных вещей делается код не соответствующий этм очевидным вещам. Так что в любом случае приходится разъяснять снова и снова...
чаще всего я сталкивался с:
-----
Проблема малых сроков - в принципе это проблема квалификации. На практике мне уже приходилось говорить НЕТ, если сроки были нереальными, но оценить с точностью до 10% более чем трехмесячную работу Я не возьмусь. Об сейлах - речь вообще не идет - они не знают об чем говорят... Кажется это позиция Д.
изменения архитектуры
-----
Хммм... Надо будет посмотреть по срокам - как раз намечается доработка с перелопачиванием одного старого проекта. Как раз будет меняться все - сиквеловские процедуры будут подниматься в миддле-лайер, паралельно будет меняться транспортный уровень - DCOM в SOAP и, на сладкое, среда разработки с BCB ни .Net... Сильно сложно быть не должно, хотя потребует своего времени...

то тут уже ничего не сделаешь.
------
Хммм... но новый проект-то надо делать! И мало того, желательно не только делать, но и сделать в срок.
пару дней, в лучшем случае
------
Т.е. очень поверхностный анализ. По-моему - можно опустить - та же неделя, потраченная на работу над проектом, будет более полезна.
Все равно у тебя будет тоже свое субъективное мнение.
------
Что Я пытаюсь для себя выяснить - будет ли мое субъектиное мнение мнением М или оно все еще мнение Д. :)
и пар выпустить полезно
------
Ты, кстати, не знаешь, какой момент наиболее критичен? Это Я могу подсказать - начальный, на перегретом котле... Перенося это на разработку Я бы предпочел нагрузить команду чем-нибудь относительно легким и гарантированно успешным, а не ковырять на предмет причин срыва... Это, наверное, все же Д...

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

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

А что даст более детальный анализ? Главное углядеть основные проблемы. И если проблемы внутренние, то можно опять на них напоротся.

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

Так ты будешь тренировать команду или делать проект?

поскольку в начале все может казаться нормальным, все будут энергичны и т.п.
------
В начале все и так будут энергичными... если не спровоцировать серьезный кризис тяжелым разбором полетов по проваленному проекту... Последний раз, при подобном разборе, Я просто ушел... не прощаясь... и больше не искал работу в той с(т)ране. :)
не всегда можно сказать нет
-----
Можно. Даже при работе на забугорного заказчика...