_>А как быть тогда разработчикам? Если спускается сверху спецификация (состоящая из одних экранных форм), нужно оценить каждую форму в часах, и если сроки не выдерживаются (именно вот эти идеальные сроки) — прессуют по самое немогу.
Если вот прямо так авторитарно, и чтоб разработчиков вообще ни о чем не спрашивали — создавайте буфера (buffers). Какого размера — вообще говоря, в традиционном менеджменте ("спустили задание") это должен знать Team Lead. Минимальный размер буфера, который вообще можно представить — 20% (но это экстрим, и только для очень опытных разработчиков, которые уже ТОЧНО знают, сколько им делать — вот они ошибаются как раз на эти проценты). Другой экстрим — это правило "умножения на Пи", когда все оценки разработчиков умножают на 3,14(15926).
Но это все равно контрпродуктивно. Разработчики все-таки люди ценные и их всегда не хватает (еще ни разу не встречал конторы, которой хватало бы разработчиков, и которая могла бы легко этими сотрудниками расшвыриваться — в отличие от разных управленцев, аналитиков, и даже QA).
Продуктивнее — идти итеративным подходом и пересматривать оценки, например, раз в неделю (или две, или три, но не реже). Чем дольше вы работаете с системой, тем больше накапливается знания и понимания того, какими должны были быть оценки. Так, например, изначальные оценки были "3 дня на фичу А, 5 на фичу Б, 10 на В, 4 на Г". Через неделю выяснилось, что сделали только "А", ошиблись в оценках в 1.7 раза (неделя = 5 дней = 3 * 1.7). Остальные оценки можно либо механически умножить на 1.7, либо творчески сесть и поставить новые оценки — с учётом новых знаний про систему (например, может статься, что во время реализации А много времени ушло на создание нужных хелпер-классов, и фичи Б, В и Г будет сделать проще, чем думалось изначально).
Выше это были объяснения на пальцах. Если почитать классиков всякого Agile'а, можно почерпнуть много больше и в куда более академическом изложении. Главное — не воскликнуть "Эврика!" и не начать нести agile в массы — вас все равно не поймут, слишком большая инертная масса...
SD>Минимальный размер буфера, который вообще можно представить — 20% (но это экстрим, и только для очень опытных разработчиков, которые уже ТОЧНО знают, сколько им делать — вот они ошибаются как раз на эти проценты). Другой экстрим — это правило "умножения на Пи", когда все оценки разработчиков умножают на 3,14(15926).
Для придирастов, на всякий случай скажу — да, я помню про cone of uncertainty, который предполагает +-80% (т.е. оценки могут варьироваться как в +80%, так и в -80%). Но, во-первых, это уже более продвинутое дао, чем просто "буфер", и к нему нужно еще придти. Во-вторых, я за более чем 10 лет так ни разу и не видел, чтобы программисты успели не то что на 80% быстрее запланированного, а даже на 30% (на 20% видел).
Здравствуйте, SkyDance, Вы писали:
SD>Если вот прямо так авторитарно, и чтоб разработчиков вообще ни о чем не спрашивали — создавайте буфера (buffers). Какого размера — вообще говоря, в традиционном менеджменте ("спустили задание") это должен знать Team Lead. Минимальный размер буфера, который вообще можно представить — 20% (но это экстрим, и только для очень опытных разработчиков, которые уже ТОЧНО знают, сколько им делать — вот они ошибаются как раз на эти проценты). Другой экстрим — это правило "умножения на Пи", когда все оценки разработчиков умножают на 3,14(15926).
Ситуация такая, что тим-лида нет. Есть просто 5 разработчиков, что-то чуть послабее, кто-то чуть посильнее. И если создавать буфер, то возникают вопросы. Например сейчас я делаю проект один и вопросы типа — вот такой же примерно раздел в другом проекте делался 2 дня, почему здесь 3 дня?
Хотя в том вот проекте (или нескольких) это все делалось со спринтерской скоростью, там на поддержке черт ногу сломит. У меня реальные сроки получаются как раз в 1.5-2 раза больше того, что было оценено. Притом, что каждый день возникают десятки вопросов по недоработкам спецификации, на каждый из которых уходит время. А менеджер свирепствует, т.к. есть очень жесткие сроки, которые примерно соответствуют идеальным оценкам.
11.04.2011 10:39, michael_isu пишет:
> > Ситуация такая, что тим-лида нет. Есть просто 5 разработчиков, что-то > чуть послабее, кто-то чуть посильнее. И если создавать буфер, то > возникают вопросы. Например сейчас я делаю проект один и вопросы типа — > вот такой же примерно раздел в другом проекте делался 2 дня, почему > здесь 3 дня? > Хотя в том вот проекте (или нескольких) это все делалось со спринтерской > скоростью, там на поддержке черт ногу сломит. У меня реальные сроки > получаются как раз в 1.5-2 раза больше того, что было оценено. Притом, > что каждый день возникают десятки вопросов по недоработкам спецификации, > на каждый из которых уходит время. А менеджер свирепствует, т.к. есть > очень жесткие сроки, которые примерно соответствуют идеальным оценкам.
Выхода два:
1. Журавль в небе: Разработчики самоорганизуются и начинают плавно
затягивать сроки (и оценки тоже), потиху выводя их на 1.5-2 раза
медленнее реально затраченного времени. После оного манагера возможно
уволят. А кого-то из вас назначают манагером.
2. Синица в руках: Сменить контору.
_>Ситуация такая, что тим-лида нет. Есть просто 5 разработчиков, что-то чуть послабее, кто-то чуть посильнее. И если создавать буфер, то возникают вопросы.
Так это же ваш ШАНС! Берите на себя ответственность. И имейте мужество, обсудив с коллегами, выкатить нормальную оценку, в которую вы уложитесьт — а затем в эту оценку уложиться. Покажите начальству, что с вами можно иметь дело, как со взрослыми людьми. Короче говоря, станьте лидом. Это если вам интересна такая работа (меньше программирования, больше психологии). На самом деле, большинству людей это не особо интересно.
_> Например сейчас я делаю проект один и вопросы типа — вот такой же примерно раздел в другом проекте делался 2 дня, почему здесь 3 дня?
Хм, а правда, почему? Найдите объяснение. Например, посмотрите, а БЫЛ ли сделан тот раздел в соседнем проекте за 2 дня? Или, как обычно, 2 дня делали, 3 переписывали, 5 дней интегрировали и еще 2 недели баги фиксили? До работы через TDD и итерационной разработки я обычно видел 2й вариант. Когда вроде бы всё сделано, но ничего не работает.
_>Хотя в том вот проекте (или нескольких) это все делалось со спринтерской скоростью, там на поддержке черт ногу сломит.
Вот и объясните это. Полностью невменяемое начальство — это редкий случай. Возможно, у него есть больше сведений — например, для бизнеса важно выпустить глюкалище, но завтра, чем супер-стабильный продукт, но послезавтра. Может, у него контракты на поставку горят.
Но вообще, раз у вас есть спецификации, да еще и подробные — да вы вообще в идеальных условиях. Просто давайте разумные оценки, и при попытке наехать "а почему так долго" — нужно очень аккуратно и доходчиво объяснять, что авторитарное занижение сроков не приведет к тому, что продукт выпустится раньше — но нервы будут у всех измотаны.
Вообще, один очень сильный консультант по SCRUM, немец, когда работал с одной (крупной) российской компанией — очень уж он удивлялся этому чисто российскому стилю менеджмента. Он называл его "Please lie to me!" Почему? Он это так объяснял: идет разработка. Приходит новая фича. Начальник (простите, но менеджером назвать его не могу) требовал дать оценки. Команда собиралась, репу чесала, прикидывала, как с наименьшими затратами сделать — и называла, допустим, 2 недели. На это начальник всегда говорил "здорово, а как можно сократить этот срок?" Если разработчики объясняли, что, в общем-то, никак — он задавал этот вопрос в стиле "давайте попробуем уменьшить трудозатраты вот тут-то". Ему объясняли, что не получится — нет необходимой поддержки со стороны другой команды. Он расцветал и обещал полную поддержку другой команды (забегу в будущее — разумеется, оной поддержки не будет). Вот из-за такого давления (и, признаюсь, малодушия членов команды, меня в том числе) назывались заниженные сроки. Их всегда срывали. Всегда. Почему? Потому что начальник требовал не сроки, а "lie to me", т.е. "ну соврите мне, скажите, что это возможно к следующей пятнице".
Почему начальнику это сходило с рук? Так ведь он со всех сторон прикрыт: гадкие разработчики ему наврали со сроками, соседняя команда не оказала посильной помощи (у нее свой начальник, однако), он сделал всё, что мог.
Вылечить ситуацию можно двумя путями. Первый — сомнительный — сменить начальника. Сомнительный — потому что непонятно, на кого, и не факт, что новый окажется менеджером, а не ровно таким же скользким типом (КМК, в 99% окажется). В конце концов, на него тоже будут "давить" сверху, и он ровно так же займется прикрытием пятой точки.
Второй путь — вводить объективные способы оценки, т.е. разделить "оценочные" идеальные часы и те часы, которых 40 в рабочей пятидневной неделе. И вводить поправочный коэффициент (в SCRUM зовут его — velocity), который будет определять отношение между "идеальными" и "реальными" часами.
Ах да, самое главное забыл. Надо наладить систему приоритезации фич, а также процесс выбрасывания фич из очередного релиза. Тогда все будет много проще — если надо "к следующей пятнице", тупо выбрасывается всё, что явно не успевается.
V>1. Журавль в небе: Разработчики самоорганизуются и начинают плавно V>затягивать сроки (и оценки тоже), потиху выводя их на 1.5-2 раза V>медленнее реально затраченного времени. После оного манагера возможно V>уволят. А кого-то из вас назначают манагером.
Так ведь он же написал — манагеров нет. Значит, как раз там синица и закопана: надо становиться лидом. Отличный шанс. Кстати, не факт, что тот, кого "назначат" манагером, будет лучше — на него так же будет давить начальство. А раз он и раньше не держал давление (соглашался на заниженные сроки), то и потом не будет.
V>2. Синица в руках: Сменить контору.
Это очень спорный вопрос. Упускать шанс на лидерство — неправильно. Сменить контору? На что? А будет ли польза?
12.04.2011 2:02, SkyDance пишет:
> > Это очень спорный вопрос. Упускать шанс на лидерство — неправильно.
Не все хотят и могут быть лидерами.
> Сменить контору? На что? А будет ли польза?
Это уже пусть ТС сам разбирается. Что там за конторы в округе есть?
12.04.2011 1:58, SkyDance пишет:
> > Вот и объясните это. Полностью невменяемое начальство — это редкий > случай.
Не такой уж и редкий.
> Потому что начальник требовал не сроки, а "lie to me", т.е. "ну соврите > мне, скажите, что это возможно к следующей пятнице". > > Почему начальнику это сходило с рук? Так ведь он со всех сторон прикрыт: > гадкие разработчики ему наврали со сроками, соседняя команда не оказала > посильной помощи (у нее свой начальник, однако), он сделал всё, что мог.
Как знакомо.
> > Вылечить ситуацию можно двумя путями.
Посмотрел бы я на твои действии при противодействии такого начальника
этим путям.
Из 5-и человек (вроде столько было упомянуто) хоть один да хочет. Вот и давайте ему поддержку — будет настоящий лидер, не назначенный, а тот, кто сам хотел, и кого поддержали.
>> Почему начальнику это сходило с рук? Так ведь он со всех сторон прикрыт: >> гадкие разработчики ему наврали со сроками, соседняя команда не оказала >> посильной помощи (у нее свой начальник, однако), он сделал всё, что мог. V>Как знакомо.
Начальники на пост-советском пространстве в значительной части одинаковы. Увы.
>> Вылечить ситуацию можно двумя путями. V>Посмотрел бы я на твои действии при противодействии такого начальника V>этим путям.
Пообщаться (с аргументами, а не пустыми обвинениями) с начальством повыше. Вообще, в любой иерархии, если вдруг происходит "перескок ступени" (как там пишут, "через голову начальника"), это сразу вызывает подозрение и более пристальное внимание к тому "начальнику", через голову которого происходит "перепрыг". Потому что, как говорил Винни-Пух, "это ж-ж-ж неспроста, само же дерево жужжать не может". Вон, соседняя ветка это здорово подтверждает.
Тут основной вопрос — готов ли автор к бочкам г---а, в которые придется многократно заныривать, если действительно что-то хочется изменить к лучшему. В моей практике подобное случалось не единожды. И размеры бочки (а также консистенция субстанции) каждый раз становились всё больше. Сначала это была борьба с технической неграмотностью "начальника" (которая чуть не разрушила проект). Для проекта это было хорошо — начальника того вы итоге "сослали" (есть такой способ без выливания тонн дерьма убрать плохого руководителя — передвинуть его на "новый проект", в котором людей еще нет — и, хаха, в будущем тоже на самом деле не будет), проект начал оживать. Но когда на проект пришли ресурсы, туда же пришли и корпоративные паразиты, а к этому никто не был готов. И после полутора лет передышки в проекте опять началась ж..а. "И вновь продолжается бой". В какой-то момент наступает психологическая готовность в любой момент бросить к чертям контору, где работаешь (даже если прикипел к ней, и к коллегам). И это будет самым продуктивным периодом в борьбе — когда терять нечего, когда плевать на угрозы начальства (а что оно может сделать? уволить? а пофигу, пущай увольняет).
Единственное, о чем хочется предупредить автора — ратуя за проект и комфортную (продуктивную) работу разработчиков, лично для себя никакой выгоды получить не удастся. Зарплата не вырастет, уважения не добавится. Максимум, что может быть — дадут грамоту "Молодец, много старался". А так, даже коллеги вряд ли оценят — с их позиций может показаться, будто все битвы против неграмотного начальства целью своей являли лишь "смену власти".
В общем, у меня опыт участия в проектах с отвратительно подобраной "обвязкой" команды (т.е. разработчики — ну просто суперские, но менеджмент — просто караул) существенный. Жаль, что он в значительной части так и остался антипаттерном I told you so. Т.е. я предупреждал — говорил, что надо делать вот так, иначе будут вот такие и такие негативные эффекты для проекта/проектов (например, я говорил, что нельзя занижать сроки путём давления на разработчиков — нельзя делать pleas lie to me). На меня либо ругались, либо говорили, что я ничего не понимаю. По прошествии определенного времени (обычно достаточно большого) — все происходило ровно так, как я и предсказывал. Да, я предупреждал. Меня не слушали. Получали то, о чем я предупреждал. Но вместо того, чтобы начинать слушать — наоборот, начинали страшно злиться и еще больше ругаться.
Справедливости ради, это было лишь в одной конторе, и, более того, лишь в одном конкретном направлении (департаменте, если угодно). Некие намёки на то были и в другой московской конторе, но там я изначально пришел с настроением "я не боюсь угроз увольнения" — и принес много ценных идей и знаний. Которые, жаль, слегка опередили время и уровень развития той компании. Сейчас уже около года я там не работаю, и вот они как раз дозревают до понимания. Искренне желаю им удачи — и думаю, у них получится, там менеджмент куда более вменяемый. Имена контор раскрывать не буду, но скажу — это, по российским меркам, практически гиганты
Сейчас я не работаю в России. Здесь ситуация противоположная: меня слушают и делают так, как надо, и как я говорю. Проект прёт как на дрожжах — он _уже_ окупился, менее чем за год, и, надеюсь, скоро будет на нем заработан первый миллион. А сейчас набираем еще людей и идем распространяться в другие страны. Маленький такой стартап
Тоже иду по этому пути — ещё в январе по другому проекту предсказывал надвигающиеся проблемы — как раз оценили все очень оптимистично, очень оперативно начали реализовывать модули, спустя 6 месяцев треть времени уходит на фиксинг багов, в один из дней недавно менеджер даже сказал в сердцах разработчикам проекта — "осталось вот этому отвалиться и вообще ничего работать не будет". Спросил так ехидно у него — "ну что, апокалипсис наступает? ". Ответить было нечего.
_>Тоже иду по этому пути — ещё в январе по другому проекту предсказывал надвигающиеся проблемы — как раз оценили все очень оптимистично, очень оперативно начали реализовывать модули, спустя 6 месяцев треть времени уходит на фиксинг багов, в один из дней недавно менеджер даже сказал в сердцах разработчикам проекта — "осталось вот этому отвалиться и вообще ничего работать не будет". Спросил так ехидно у него — "ну что, апокалипсис наступает? ". Ответить было нечего.
Вот, как ни странно, я с высоты нынешнего опыта, наверное, посоветовал бы не повторять мой путь. Ну да, я неслабо так почесал своё эго в итоге. Прокачал скиллы на предмет составления всяких бумаг, планов, прогнозов, учётов и т.п. Но кроме морального злорадства ничего не получил. А вот нервов потерял предостаточно — и овертаймов отсидел выше крыши. Если у вас действительно предапокалиптическая ситуация, то я присоединюсь к рекомендацияю Vzhik оглянуться по сторонам на предмет других контор поблизости. Даже если вы и не захотите никуда переходить, у вас хотя бы появится здоровый пофигизм на тему увольнения — это и нервы помогает сберечь, и уверенности придает (а уверенность — очень важный фактор при разговоре с любым начальством).
Но ситуация у вас прямо классическая для российской разработки
14.04.2011 2:40, SkyDance пишет:
> > Из 5-и человек (вроде столько было упомянуто) хоть один да хочет. Вот и > давайте ему поддержку — будет настоящий лидер, не назначенный, а тот, > кто сам хотел, и кого поддержали.
Если у этого лидера есть голова, то он прежде подумает, чем брать на
себе не понять что.
> > Начальники на пост-советском пространстве в значительной части > одинаковы. Увы.
Такова здесь жизнь.
> >> > Вылечить ситуацию можно двумя путями. > V>Посмотрел бы я на твои действии при противодействии такого начальника > V>этим путям. > > Пообщаться (с аргументами, а не пустыми обвинениями) с начальством
Опущу, все что ты написал. По сути вопрос: Добился ты того, чего хотел в
результате этих разборок?
Я предполагаю, что понырять в бочки с Г. не было твоей целью.
> > Сейчас я не работаю в России. Здесь ситуация противоположная: меня > слушают и делают так, как надо, и как я говорю. Проект прёт как на > дрожжах — он _уже_ окупился, менее чем за год, и, надеюсь, скоро будет > на нем заработан первый миллион. А сейчас набираем еще людей и идем > распространяться в другие страны. Маленький такой стартап
А где объявы? Планируете ли в Беларуси? Где планируете людей набирать?
Тут сейчас сильно зарплаты програмерские просели.
14.04.2011 3:15, michael_isu пишет:
> > Тоже иду по этому пути — ещё в январе по другому проекту предсказывал > надвигающиеся проблемы — как раз оценили все очень оптимистично, очень > оперативно начали реализовывать модули, спустя 6 месяцев треть времени > уходит на фиксинг багов, в один из дней недавно менеджер даже сказал в > сердцах разработчикам проекта — "осталось вот этому отвалиться и вообще > ничего работать не будет". Спросил так ехидно у него — "ну что, > апокалипсис наступает? ". Ответить было нечего.
Ну если ты все нюансы не учел скоро уволишься.
Здравствуйте, SkyDance, Вы писали:
SD>Вот, как ни странно, я с высоты нынешнего опыта, наверное, посоветовал бы не повторять мой путь. Ну да, я неслабо так почесал своё эго в итоге. Прокачал скиллы на предмет составления всяких бумаг, планов, прогнозов, учётов и т.п. Но кроме морального злорадства ничего не получил. А вот нервов потерял предостаточно — и овертаймов отсидел выше крыши. Если у вас действительно предапокалиптическая ситуация, то я присоединюсь к рекомендацияю Vzhik оглянуться по сторонам на предмет других контор поблизости. Даже если вы и не захотите никуда переходить, у вас хотя бы появится здоровый пофигизм на тему увольнения — это и нервы помогает сберечь, и уверенности придает (а уверенность — очень важный фактор при разговоре с любым начальством).
SD>Но ситуация у вас прямо классическая для российской разработки
Да-да, овертаймы, все дела.
Уже обновил резюме, насыпалось куча предложений прийти пообщаться, вздохнуть можно легче. Теперь буду более скурпулезно подходить к выбору проектов и менеджмента. Самому конечно хочется стать лидом, но нужны ещё скиллы в разработке, не верю я что можно адекватно менеджерить, если сам хотя бы до серьера не дорос.
V>Если у этого лидера есть голова, то он прежде подумает, чем брать на V>себе не понять что.
Это само собой. Но если проект действительно нужен конторе (косвенный признак — увеличение денежных расходов и внимания начальства), то даже при плохой ситуации можно его исправить. А если видно, что начальство, напротив, уводит людей и бюджеты с проекта (понятно, что крайне незаметно, чтобы не создавать панику), то тут все просто, надо уходить.
V>Опущу, все что ты написал. По сути вопрос: Добился ты того, чего хотел в V>результате этих разборок?
На первой итерации добился — неграмотного "начальника" убрали. Поставили куда более грамотного. Это была большая победа и проект пошел намного лучше.
V>Я предполагаю, что понырять в бочки с Г. не было твоей целью.
Целью (я тогда был моложе и бездетнее) было участие в хорошем проекте и выход интересного и полезного продукта, который бы на равных конкурировал с самым известным и раскрученным конкурентом. В общем-то, у нас тогда был реальный шанс превзойти тех самых конкурентов и стать первыми в мире в этой ОЧЕНЬ прибыльной области софтостроения (которая только сейчас начинает входить в массы — а мы делали это 5 лет назад). Я искренне в это верил и до сих пор верю, если бы тогда руководство хоть сколько-то внимания уделяло умным коллегам — сейчас бы компания стоила много больше (хотя и так компания большая). Да и я мог бы заработать на обещаный в те годы "домик в Вёшках" (С).
V>А где объявы? Планируете ли в Беларуси? Где планируете людей набирать?
Да какая Белоруссия, Новая Зеландия и Индия
А набирать, само собой, в Австралии, где я сейчас.
_>Теперь буду более скурпулезно подходить к выбору проектов и менеджмента.
Отрицательный опыт тоже опыт. Одна сложность, в России вообще тяжко с адекватным менеджментом. Но я с таким встречался — причем даже в одной очень большой компании. Не рискну ее рекламировать публично, но у меня о ней остались самые лучше воспоминания.
_>Самому конечно хочется стать лидом, но нужны ещё скиллы в разработке, не верю я что можно адекватно менеджерить, если сам хотя бы до серьера не дорос.
Бойтесь своих желаний, они сбываются.
Если хочется стать лидером "из-за денег" — лучше не надо, за деньгами правильнее просто уезжать из России (в США, Австралию, Канаду), оставаясь высококлассным программистом.
14.04.2011 18:00, michael_isu пишет:
> Уже обновил резюме, насыпалось куча предложений прийти пообщаться, > вздохнуть можно легче. Теперь буду более скурпулезно подходить к выбору > проектов и менеджмента. Самому конечно хочется стать лидом, но нужны ещё > скиллы в разработке, не верю я что можно адекватно менеджерить, если сам > хотя бы до серьера не дорос.
В нормальном менеджерении главное — работы с людьми (выше- и
нижестоящими), профессиональные скилы вторичны. При правильном вашем
подходе ваши подчиненные сделают все сами.
Здравствуйте, AlexNek, Вы писали: AN>Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был. AN>Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
Просто интересно, что имеется в виду под "сделавший один"? Имеется в виду, что их было двое и ПМ руководил программистом? Такое бывает?
Здравствуйте, jeeist, Вы писали:
J>Здравствуйте, AlexNek, Вы писали: AN>>Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был. AN>>Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
J>Просто интересно, что имеется в виду под "сделавший один"? Имеется в виду, что их было двое и ПМ руководил программистом? Такое бывает?
Нет, имеется в виду, что кроме этого программиста был только заказчик. Отчего требуется еще и руководитель?
