Комментарии 71
НЛО прилетело и опубликовало эту надпись здесь
Вот ведь я ж норкоман-то :) Про Trainspotting не знал.
Ну, у меня было время порефлексировать, теперь делюсь опытом.
Как говорится — спонсор этого вечера — фраза «надо было тогда не так сказать».
Ну, у меня было время порефлексировать, теперь делюсь опытом.
Как говорится — спонсор этого вечера — фраза «надо было тогда не так сказать».
Я вот до сих пор не понял почему тим лид отвечает за деньги.
За время — отвечает, за деньги это какой то цирк с конями.
Грамотный менеджер/финансист быстрее выбьет денег на доработки, нежели тех спец.
а по поводу заваленных сроков на 1/5 при оплате за каждую 1/4 почему не было видно на первых 3/5 что проблема уже есть?
При таком раскладе супервайзеру проекта нужно вставить люлей за то, что не проконтролировал, тим лиду вставить люлей за вытягивание сроков. А остальные — люди подневольные.
За время — отвечает, за деньги это какой то цирк с конями.
Грамотный менеджер/финансист быстрее выбьет денег на доработки, нежели тех спец.
а по поводу заваленных сроков на 1/5 при оплате за каждую 1/4 почему не было видно на первых 3/5 что проблема уже есть?
При таком раскладе супервайзеру проекта нужно вставить люлей за то, что не проконтролировал, тим лиду вставить люлей за вытягивание сроков. А остальные — люди подневольные.
К примеру, я за год изучил AngularJS 1, VUE,js 2, Twitter Bootstrap 3, Semantic UI 2, M.E.A.N., Phalcon 3, Yii 2, Laravel 5, Grunt, SCSS. Прокачался так, что голова кружится от ощущения собственной крутоты.
Хорошая иллюстрация эффекта Даннинга-Крюгера.
Голова покружилась и прошла. Навыки остались. Ещё пригодятся.
Есть у меня ещё один навык, который получился в прошлом году. Я бы описал его так: насколько бы хорошо я не знал тему вопроса, нужно свой ответ отложить на самый последний момент, когда все высказались. Дай сказать всем, вытягивай из них мнения и решения. Ох, это сложно, особенно когда у меня решение крутится на языке и готово соскочить в любой момент. Но ради общего повышения навыка принятия решений нужно заткнуться и дать людям совершать ошибки, чтобы они учились. Я сам ошибался, на этом и учился. Нельзя других лишать возможности стать лучше.
Есть у меня ещё один навык, который получился в прошлом году. Я бы описал его так: насколько бы хорошо я не знал тему вопроса, нужно свой ответ отложить на самый последний момент, когда все высказались. Дай сказать всем, вытягивай из них мнения и решения. Ох, это сложно, особенно когда у меня решение крутится на языке и готово соскочить в любой момент. Но ради общего повышения навыка принятия решений нужно заткнуться и дать людям совершать ошибки, чтобы они учились. Я сам ошибался, на этом и учился. Нельзя других лишать возможности стать лучше.
Вообще получалось так, что мои решения, болтающиеся на кончике языка, не были уникальными идеальными решениями. Команда выбирает такие же (то есть моё — не уникальное) и даже более удобные (то есть моё — не идеальное). Поэтому и утверждение, кто никто не умнее других в команде. А помолчать надо, чтобы они не стеснялись аргументированно выбирать решения.
>Команда выбирает такие же (то есть моё — не уникальное) и даже более удобные (то есть моё — не идеальное). Поэтому и утверждение, кто никто не умнее других в команде.
Правильно будет сказать, что вы не умнее остальных в команде. Обобщать это утверждение на всех остальных — неправильно.
Правильно будет сказать, что вы не умнее остальных в команде. Обобщать это утверждение на всех остальных — неправильно.
>>Прокачался так, что голова кружится от ощущения собственной крутоты. Но в решениях компании, где я работаю, эти технологии не используются.
Несколько месяцев назад начал понемногу изучать python и совсем недавно nodejs. Чисто в самообразовательных целях, чтобы мозг не усыхал. И вот прямо на днях пришлось поднимать все знания, чтобы выбрать правильные решения для одного серьезного проекта. Неделя гугления и творчества и некий девайс подключен к компу с убунтой и они обмениваются данными. :) Теперь надо углубляться в Gtk3, чтобы дизайн был не в стиле HelloWorld.
ЗЫ Сам себя не похвалишь, никто не похвалит :)
Несколько месяцев назад начал понемногу изучать python и совсем недавно nodejs. Чисто в самообразовательных целях, чтобы мозг не усыхал. И вот прямо на днях пришлось поднимать все знания, чтобы выбрать правильные решения для одного серьезного проекта. Неделя гугления и творчества и некий девайс подключен к компу с убунтой и они обмениваются данными. :) Теперь надо углубляться в Gtk3, чтобы дизайн был не в стиле HelloWorld.
ЗЫ Сам себя не похвалишь, никто не похвалит :)
Мой опыт подсказывает мне, что остаток в 20% сформировался не в последний день сдачи проекта. Такие риски реализуются ДО финала, а величина этого риска и характер (архитектурный) говорят о том, что он реализовался, если не сразу, то в конце первой половины — начале второй половины (срока) проекта. Так что ПМ и тимлид просто не смогли (или не захотели) увидеть этот риск. И указанные в начале статьи три финала — все результат более ранней ошибки.
Нельзя архитектора одного винить за плохую архитектуру. Как правило, архитектура после ее описания еще какое-то время от начала полируется и правится. И, если, с ней неудобно работать, она не выполняет своих целей, то кто-то в команде просто забил и сказал «ааа, не беда, накостылю», вместо того чтобы пойти к архитектору и сказать что он ошибся или спросить как решать такие-то и такие-то задачи.
Нельзя архитектора одного винить за плохую архитектуру. Как правило, архитектура после ее описания еще какое-то время от начала полируется и правится. И, если, с ней неудобно работать, она не выполняет своих целей, то кто-то в команде просто забил и сказал «ааа, не беда, накостылю», вместо того чтобы пойти к архитектору и сказать что он ошибся или спросить как решать такие-то и такие-то задачи.
Это же задача с собеседования. Там вопрос наигранный, гипотетический. Проверяет как кандидат мыслит терминами компании, команды и проекта.
> указанные в начале статьи три финала — все результат более ранней ошибки
Согласен
> указанные в начале статьи три финала — все результат более ранней ошибки
Согласен
Понятно что вопрос гипотетический, но, на мой взгляд, он выглядит как «мы профакапили и надо найти кого наказать». Т.е. он не направлен на поиск причин, а только на то «как выйти из ситуации с наименьшими потерями».
В целом, я согласен, для фирмы третий вариант предпочтительнее, на короткой дистанции. Т.е. прямо сейчас сохраняется команда (вопрос только, а стоит ли), сохраняется репутация (только какая, что фирма не увидела приближающийся факап?) и фирма не выходит в минус.
Только вот, с точки зрения клиента, я бы с такой фирмой дел иметь не стал и этот проект был бы с ней последний.
Опять-таки, у клиента могут быть свои планы на дату финала проекта, у него может быть запланирована грандиозная распродажа или другая акция, закуплены товары, арендованы площадки. В общем, он УЖЕ потратился. И фирма ему врала все это время, что все закончится вовремя и все будет хорошо.
Я, как-то, погрузился в историю одной ИТ системы для аэропорта. Суть в том, что разработчик обещал сдать систему вовремя, и заказчик уже распланировал мероприятия, расписал бюджеты и начал даже их тратить. И в последний момент оказалось что система не готова. Суммы за простой аэропорта там были астрономические. А сроки до сдачи в эксплуатацию системы составляли еще несколько месяцев после формальной сдачи проекта.
В общем, если бы дело было в Китае или в Японии, то, думаю, все закончилось бы человеческими «жертвоприношениями». Чем закончилась история с аэропортом для разработчика, история умалчивает.
Все эти примеры, конечно, не касаются гипотетического вопроса на собеседовании, но в таких случаях всегда надо понимать, что сдача проекта это событие не только для разработчика, но и для заказчика, и последний, может нести дополнительные убытки от таких «замалчиваний».
В целом, я согласен, для фирмы третий вариант предпочтительнее, на короткой дистанции. Т.е. прямо сейчас сохраняется команда (вопрос только, а стоит ли), сохраняется репутация (только какая, что фирма не увидела приближающийся факап?) и фирма не выходит в минус.
Только вот, с точки зрения клиента, я бы с такой фирмой дел иметь не стал и этот проект был бы с ней последний.
Опять-таки, у клиента могут быть свои планы на дату финала проекта, у него может быть запланирована грандиозная распродажа или другая акция, закуплены товары, арендованы площадки. В общем, он УЖЕ потратился. И фирма ему врала все это время, что все закончится вовремя и все будет хорошо.
Я, как-то, погрузился в историю одной ИТ системы для аэропорта. Суть в том, что разработчик обещал сдать систему вовремя, и заказчик уже распланировал мероприятия, расписал бюджеты и начал даже их тратить. И в последний момент оказалось что система не готова. Суммы за простой аэропорта там были астрономические. А сроки до сдачи в эксплуатацию системы составляли еще несколько месяцев после формальной сдачи проекта.
В общем, если бы дело было в Китае или в Японии, то, думаю, все закончилось бы человеческими «жертвоприношениями». Чем закончилась история с аэропортом для разработчика, история умалчивает.
Все эти примеры, конечно, не касаются гипотетического вопроса на собеседовании, но в таких случаях всегда надо понимать, что сдача проекта это событие не только для разработчика, но и для заказчика, и последний, может нести дополнительные убытки от таких «замалчиваний».
Как пишут, первый iPhone показывали не 100% работающим :)
> «как выйти из ситуации с наименьшими потерями»
Первые три вариант финала — да, поиск такого варианта.
Такое со мной случилось бы только в случае, если мне уже сунули в руки дохнущий проект. Пришлось бы извиваться и запускать сырой, прикрыв дыры, чтобы не срывать сроки, искать свободные руки и финансы для завершения, а то и дописывать наравне с другими. В случае провала мне пришлось бы уйти, дабы не чинить расправы над выдохшейся командой.
В разработке ПО финал с человеческими жертвоприношениями — это если фейл обнаружится в системе управления космическим кораблём, логике самоуправляемого автомобиля,Скайнете, автоматической системе жизнеобеспечения в медицине. Причём умер бы конечный пользователь. А разработчик максимум отсидел бы срок, но всяко не смертная казнь. Скайнет не всчёт. Китай не в счёт.
В определённом смысле это всё риск. Надо быть готовым ко всему. Мы можем зафакапить презентацию, но и заказчик может разориться ещё до наступления года. Контрольные точки, спринты, ретроспективы — они для того, чтобы не получить фейл через год, а приблизить во времени цепочку обратной связи от заказчика и конечных пользователей. Получить фейл через 3 месяца, например.
Последний абзац, финал римейка:
Это и есть тот вариант, что мы уже давно его запустили, теперь собираем баги и дописываем код по ТЗ. Всё пучком.
> «как выйти из ситуации с наименьшими потерями»
Первые три вариант финала — да, поиск такого варианта.
Такое со мной случилось бы только в случае, если мне уже сунули в руки дохнущий проект. Пришлось бы извиваться и запускать сырой, прикрыв дыры, чтобы не срывать сроки, искать свободные руки и финансы для завершения, а то и дописывать наравне с другими. В случае провала мне пришлось бы уйти, дабы не чинить расправы над выдохшейся командой.
В разработке ПО финал с человеческими жертвоприношениями — это если фейл обнаружится в системе управления космическим кораблём, логике самоуправляемого автомобиля,
В определённом смысле это всё риск. Надо быть готовым ко всему. Мы можем зафакапить презентацию, но и заказчик может разориться ещё до наступления года. Контрольные точки, спринты, ретроспективы — они для того, чтобы не получить фейл через год, а приблизить во времени цепочку обратной связи от заказчика и конечных пользователей. Получить фейл через 3 месяца, например.
Последний абзац, финал римейка:
И, скорее всего, оно уже даже эксплуатируется. Команда поддержки уже собирает отзывы, рекомендации, предложения, баг-репорты от конечных пользователей. Тестировщики тестируют. Дизайнеры и верстальщики улучшают интерфейс. Команда разработчиков уже доделывает проект.
Это и есть тот вариант, что мы уже давно его запустили, теперь собираем баги и дописываем код по ТЗ. Всё пучком.
В случае аэропорта (или аналогичной ситуации, когда срыв сроков ведет к крупным потерям) или они нанимают фирмы (и заключают правильные договора), которые «если что» смогут «ответить» возместив потери и почти не контролируют их работу (обычно это очень крупные фирмы, которые сами себя проконтролируют, что бы не потерять средства) или очень строго контролируют сроки поэтапно, в случае затягивания очень быстро меняют исполнителя…
Либо все сроки надо умножить как минимум на два, но не говорить об этом исполнителям — успеют раньше — отлично, не успеют — пусть заканчивают, но платят неустойки «что бы не было повадно» остальным и на будущее…
Либо все сроки надо умножить как минимум на два, но не говорить об этом исполнителям — успеют раньше — отлично, не успеют — пусть заканчивают, но платят неустойки «что бы не было повадно» остальным и на будущее…
НЛО прилетело и опубликовало эту надпись здесь
Мне любопытно, что бы автор сделал, если бы заказчик попался не глупый, и на пред-дедлайновом совещании задал вам совершенно конкретный вопрос, ожидая конкретного ответа — готова ли на данный момент фича N (из нереализованных 20%)?
На мой взгляд, если вы нарушили договор, вам так или иначе придется доделывать эти 20% бесплатно, и выкачать дополнительные деньги за реализацию дополнительных фич вряд ли получится (по-крайней мере, до 100% сдачи проекта).
На мой взгляд, если вы нарушили договор, вам так или иначе придется доделывать эти 20% бесплатно, и выкачать дополнительные деньги за реализацию дополнительных фич вряд ли получится (по-крайней мере, до 100% сдачи проекта).
флексить :) дурацкий термин, означающий что можно попробовать сдать в эксплуатацию путём урезания чего-нибудь, не в ущерб продукту в целом.
Сейчас я отвечу на такой вопрос только если мне дадут конкретный пример и возможность пообщаться с командой. Без этого я все свои пришедшие на ум советы помечу ярлычком «draft», рабочий вариант.
Бесплатно доделать — это вариант, озвученный в финале. Потому что у моей команды есть резерв. Но там не было бы 20% архитектурно-несовместимых решений.
Сейчас я отвечу на такой вопрос только если мне дадут конкретный пример и возможность пообщаться с командой. Без этого я все свои пришедшие на ум советы помечу ярлычком «draft», рабочий вариант.
Бесплатно доделать — это вариант, озвученный в финале. Потому что у моей команды есть резерв. Но там не было бы 20% архитектурно-несовместимых решений.
Я имел ввиду, что вы бы сказали заказчику на месте? Что вам необходимо уточнить этот момент у команды?
Вообще, постановка задачи странная — 80% реализовать можно, а 20% — никак нельзя в текущей архитектуре?
При планировании такие риски должны были быть четко видны, теоретически. Получается, проект уже был «провален» на начальной стадии.
Вообще, постановка задачи странная — 80% реализовать можно, а 20% — никак нельзя в текущей архитектуре?
При планировании такие риски должны были быть четко видны, теоретически. Получается, проект уже был «провален» на начальной стадии.
Если бы я знал что через год 20% не могут быть сделаны, я ещё до встречи с заказчиком все детали у команды выяснил. И пути решений составили бы. В целом конечно это означает «спросил у команды», но не так явно, чтобы не работать прослойкой между командой и заказчиком.
Только в моей истории я бы не дошёл до «20% не могут быть сделаны, ой» через год. Потому есть техники, которые позволяют выявить проблемы до финальной стадии сдачи. Промежуточные релизы, тестирование на контрольной группе, альфа-версии, бета-версии.
Потому что есть понятие MVP, согласно которому система реализуется частями, при котором за каждый контрольный срок реализации система дописывается сразу по всем аспектам, а не вылизывается один единственный аспект.
Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.
Только в моей истории я бы не дошёл до «20% не могут быть сделаны, ой» через год. Потому есть техники, которые позволяют выявить проблемы до финальной стадии сдачи. Промежуточные релизы, тестирование на контрольной группе, альфа-версии, бета-версии.
Потому что есть понятие MVP, согласно которому система реализуется частями, при котором за каждый контрольный срок реализации система дописывается сразу по всем аспектам, а не вылизывается один единственный аспект.
Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.
Как я и сказал, постановка задачи довольно странная: при использовании любого более-менее современного подхода к проектированию \ реализации такие проблемы должны быстро выявляться.
Спасибо за ответы.
Спасибо за ответы.
>Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.
Это всё отлично, но к сожалению, не всегда применимо.
Как пример можно привести постройку здания.
Фундамент необходимо закладывать первым.
А постройку крыши и финишную отделку придётся откладывать на самый конец строительства…
Другой вопрос что в таких проектах всё же обычно участвуют конторы с большим опытом и они могут заранее предсказать большую часть проблем и варианты решения.
Это всё отлично, но к сожалению, не всегда применимо.
Как пример можно привести постройку здания.
Фундамент необходимо закладывать первым.
А постройку крыши и финишную отделку придётся откладывать на самый конец строительства…
Другой вопрос что в таких проектах всё же обычно участвуют конторы с большим опытом и они могут заранее предсказать большую часть проблем и варианты решения.
Примеры проектов
1. Большая система чего-либо, где 20% — это искусственный интеллект. Его писали писали и ничего не получилось. Но разработчики показывали идеальную модель, отлично работающую на тестовых данных. В итоге вся система не работает.
2. Система, подразумевающая интеграцию. Но 20% этой системы находится не под контролем команды и они не готовы, хотя они отписывались об итогах и тесты проходят. В итоге вся система не работает.
3. Игра, в которой нужно определённое железо, но это за пределами программного кода проекта. Ну типа нестабильность игровой приставки. Разработчики игровой приставки обещали за год выпустить SDK с исправлениями и заменить чипы в новых версиях железа, но выпуск отложен. Вся игра работает только на пропатченных консолях у разработчиков, но они не могут патчить консоли конечных пользователей. Вся система не работает.
4. Система, в которой функционирование реализуется только путём участия третьих лиц, и привлечение этих лиц взял на себя кто-то другой, но так никого и не привели. Незнакомая ситуация? Ну представьте, что на Booking.com так и не пришли владельцы отелей. Посетители есть, отелей нет. Вся система не работает.
Это я так, наугад придумал.
1. Большая система чего-либо, где 20% — это искусственный интеллект. Его писали писали и ничего не получилось. Но разработчики показывали идеальную модель, отлично работающую на тестовых данных. В итоге вся система не работает.
2. Система, подразумевающая интеграцию. Но 20% этой системы находится не под контролем команды и они не готовы, хотя они отписывались об итогах и тесты проходят. В итоге вся система не работает.
3. Игра, в которой нужно определённое железо, но это за пределами программного кода проекта. Ну типа нестабильность игровой приставки. Разработчики игровой приставки обещали за год выпустить SDK с исправлениями и заменить чипы в новых версиях железа, но выпуск отложен. Вся игра работает только на пропатченных консолях у разработчиков, но они не могут патчить консоли конечных пользователей. Вся система не работает.
4. Система, в которой функционирование реализуется только путём участия третьих лиц, и привлечение этих лиц взял на себя кто-то другой, но так никого и не привели. Незнакомая ситуация? Ну представьте, что на Booking.com так и не пришли владельцы отелей. Посетители есть, отелей нет. Вся система не работает.
Это я так, наугад придумал.
Опять же, ни один из четырёх примеров не является внезапным факапом, сваливающимся на голову в последний день.
1. Это предсказуемые риски, которые необходимо было сразу огласить заказчику и иметь пути отступления. В идеале подобные вещи надо оформлять в рамках отдельного проекта, уже после пусконаладки основного продукта, а не делать «проект в проекте» с малыми шансами на успех.
2. Если интеграция является требованием заказчика, то это вполне можно (и нужно) объяснить заказчику. Не исключено, что он после этого сможет ускорить процесс, придав импульс нужным действующим лицам, и процесс завершится успешно. Если же вы добровольно завязали ключевую архитектуру на работавшую (на тот момент) интеграцию со сторонним сервисом, а сервис бесславно обанкротился, сломался, или поменял концепцию до окончания года — это просчитываемая ошибка.
3. Золотое правило: при разработке любой вещи ориентироваться только на то, что есть здесь и сейчас. Если на текущей версии библиотеки (приставки, чипа, операционной системы, и т.п.) код не работает, но разработчики клятвенно обещают к концу года это исправить — их слова пропускаем мимо ушей, а принимаем только то, что код не работает и надо искать обходные пути.
4. «Пользователи не пришли» — это симптом, а не болезнь. Надо разбираться, почему не пришли, что им помешало. В итоге, когда вы докопаетесь до истины, будет установлена конкретная причина, и её вы и будете конкретно решать.
1. Это предсказуемые риски, которые необходимо было сразу огласить заказчику и иметь пути отступления. В идеале подобные вещи надо оформлять в рамках отдельного проекта, уже после пусконаладки основного продукта, а не делать «проект в проекте» с малыми шансами на успех.
2. Если интеграция является требованием заказчика, то это вполне можно (и нужно) объяснить заказчику. Не исключено, что он после этого сможет ускорить процесс, придав импульс нужным действующим лицам, и процесс завершится успешно. Если же вы добровольно завязали ключевую архитектуру на работавшую (на тот момент) интеграцию со сторонним сервисом, а сервис бесславно обанкротился, сломался, или поменял концепцию до окончания года — это просчитываемая ошибка.
3. Золотое правило: при разработке любой вещи ориентироваться только на то, что есть здесь и сейчас. Если на текущей версии библиотеки (приставки, чипа, операционной системы, и т.п.) код не работает, но разработчики клятвенно обещают к концу года это исправить — их слова пропускаем мимо ушей, а принимаем только то, что код не работает и надо искать обходные пути.
4. «Пользователи не пришли» — это симптом, а не болезнь. Надо разбираться, почему не пришли, что им помешало. В итоге, когда вы докопаетесь до истины, будет установлена конкретная причина, и её вы и будете конкретно решать.
3. код не работает, но разработчики клятвенно обещают к концу года это исправить — их слова пропускаем мимо ушей,
Ну тут вопрос в чьей стороне ответственности эти разработчики.
Если со стороны заказчика — проблему надо решать или заказчику или совместно, или вам, но заказчик платит за всё.
Если со стороны исполнителя — проблема или целиком ваша или решить с заказчиком совместно, но с оплатой — зависит от частностей. Например был ли заказчик в курсе возможной ситуации (и об этом есть в ТЗ/договоре) или нет.
и тд и тп
Ну тут вопрос в чьей стороне ответственности эти разработчики.
Если со стороны заказчика — проблему надо решать или заказчику или совместно, или вам, но заказчик платит за всё.
Если со стороны исполнителя — проблема или целиком ваша или решить с заказчиком совместно, но с оплатой — зависит от частностей. Например был ли заказчик в курсе возможной ситуации (и об этом есть в ТЗ/договоре) или нет.
и тд и тп
Во всех 4х ситуациях — есть конкретный виновник, в самой команде(плохой вариант) или вне её:
1. Ответственность на тех людях, которые принимали решение, когда взяли на себя задачу по реализации данных требований(а не задачу на исследование), а также те, кто принимал решение о тестировании на неподходящих данных.
2. Ответственна та компания, которая должна реализовать необходимые 20%, соответственно — все издержки и претензии — на неё.
3. Каким-то образом был закреплён тот момент, что игра требует более новые версии железа? если да — все вопросы формально на стороне заказчика — что заказали, то и получили.
4. «привлечение этих лиц взял на себя кто-то другой» — вот этот самый другой и есть ответственный за ситуацию.
И да — во всех случаях, кроме разве что первого — проблема при должном мониторинге известна куда раньше, чем самый последний момент.
1. Ответственность на тех людях, которые принимали решение, когда взяли на себя задачу по реализации данных требований(а не задачу на исследование), а также те, кто принимал решение о тестировании на неподходящих данных.
2. Ответственна та компания, которая должна реализовать необходимые 20%, соответственно — все издержки и претензии — на неё.
3. Каким-то образом был закреплён тот момент, что игра требует более новые версии железа? если да — все вопросы формально на стороне заказчика — что заказали, то и получили.
4. «привлечение этих лиц взял на себя кто-то другой» — вот этот самый другой и есть ответственный за ситуацию.
И да — во всех случаях, кроме разве что первого — проблема при должном мониторинге известна куда раньше, чем самый последний момент.
Ну нашли вы на кого свалить всю вину. Дальше-то что?
А дальше решать проблему.
Вопрос кто за это решение будет платить и понесёт убытки — зависит от конкретики и договоров.
Это либо целиком заказчик, либо целиком исполнитель, либо какое-то совместное решение…
Вопрос кто за это решение будет платить и понесёт убытки — зависит от конкретики и договоров.
Это либо целиком заказчик, либо целиком исполнитель, либо какое-то совместное решение…
Ну, если единственная ваша проблема в том, кто за всё будет платить, то, конечно, нахождение виноватого — это уже пол дела.
Но на мой взгляд важнее следующие проблемы:
- как всё-таки решить задачу клиента, за которую он уже заплатил.
- как не потерять клиента или хотя бы репутацию и как следствие возможность дальнейшего развития.
- как не потерять команду и как следствие бизнес.
Но ок, допустим вы выяснили, кто виноват. Как правило тот, кто виноват, не примет ваших обвинений. выставляя себя жертвой обстоятельств или перекладывая вину на других. Это приведёт к конфликту. Например, вы обвинили:
- Архитектора. Он обижается и уходит. Остаётся некому выстроить правильную архитектуру.
- Разработчиков. Они обижаются и разбегаются. Некому латать дыры в тонущем корабле.
- Клиента. Он обижается и даже если и соглашается на ваши условия, то к вам больше не возвращается. А то и пустит слух, что вы не компетентны.
Заметьте, всё это независимо от обоснованности ваших обвинений.
Важно понимать, что любой конфликт в условиях ограниченных ресурсов очень быстро эскалируется до неприличных масштабов.
как всё-таки решить задачу клиента, за которую он уже заплатил.
Ключевой вопрос обычно так и звучит: а заплатил ли клиент за решение задачи?
Т.е.: корректно ли у клиента сформирована тестовая среда, по графику клиент предоставлял информацию, корректно ли были выбраны и сформулированы критерии приемки? Согласовывался ли бюджет после внесения изменений?
Клиента. Он обижается и даже если и соглашается на ваши условия, то к вам больше не возвращается. А то и пустит слух, что вы не компетентны.
Юридические основания? Аудит проекта и счет за судебные издержки за клевету и разрушение деловой репутации такому «клиенту». Сам получил «звание» Неадеквата/Сложного Клиента и т.д.
>2. Система, подразумевающая интеграцию. Но 20% этой системы находится не под контролем команды
Вариантов множество....
Если интеграция со стороны заказчика — то это не ваши проблемы.
Их решение вы можете взять на себя за отдельные деньги (и сроки)
Если интеграция с вашей стороны и заказчик не в курсе (в договоре не прописано) что вы будете что-то «брать со стороны», то это в 1ю очередь ваши проблемы.
Иногда их можно списать на форс-мажор, иногда нет.
Обычно в такой ситуации надо решать с заказчиком что и как можно сделать.
Например «таможня задержала поставку оборудования» — идет срыв сроков,
в крупных конторах обычно есть свой «подменный фонд» или даже склад, который можно временно задействовать, если у заказчика «горят сроки», если же вариантов нет — надо решать с заказчиком — или ждать или менять оборудование на совместимое или даже править код что бы заработал на аналоге — но это всё надо заранее решить с заказчиком.
Иногда заказчик может понять ваши проблемы и предложить даже своё решение или помочь решить затруднения… Иногда вы попадете на судебный иск об издержках или даже убытках.
Все зависит от очень конкретной ситуации и документов к ней.
Абстрактных примеров множество, а вариантов решения еще больше.
Если например должны поставить на Луну/Марс запас кислорода для купола, под которым живут люди — там будет речь идти об очень жестких сроках и некотором их запасе (если это не аварийная доставка, то запас должен быть, вопрос какой), а вот в случае провала всех сроков — скорее всего виновник станет причиной гибели людей. Грамотное руководство например должно рассчитывать минимум 2-3 кратный запас таких вещей, но ведь бывают и аварии с утечкой.
Что будет делать руководитель из примера в статье в этом случае?
В общем без конкретики задания такой вопрос (из статьи) можно решить только «для общего случая», а лучше всего начать задавать интервьюеру наводящие вопросы о сути задания — иногда именно этого они и ждут.
Т.е. если вы кинулись отвечать на задачу с неполными данными и дали не верный ответ — вы не пригодны. Если начали задавать нужные вопросы, но ответ был дан не совсем верно — могут взять помощником, а потом посмотреть/обучить/… и тд и тп
Их решение вы можете взять на себя за отдельные деньги (и сроки)
Если интеграция с вашей стороны и заказчик не в курсе (в договоре не прописано) что вы будете что-то «брать со стороны», то это в 1ю очередь ваши проблемы.
Иногда их можно списать на форс-мажор, иногда нет.
Обычно в такой ситуации надо решать с заказчиком что и как можно сделать.
Например «таможня задержала поставку оборудования» — идет срыв сроков,
в крупных конторах обычно есть свой «подменный фонд» или даже склад, который можно временно задействовать, если у заказчика «горят сроки», если же вариантов нет — надо решать с заказчиком — или ждать или менять оборудование на совместимое или даже править код что бы заработал на аналоге — но это всё надо заранее решить с заказчиком.
Иногда заказчик может понять ваши проблемы и предложить даже своё решение или помочь решить затруднения… Иногда вы попадете на судебный иск об издержках или даже убытках.
Все зависит от очень конкретной ситуации и документов к ней.
Абстрактных примеров множество, а вариантов решения еще больше.
Если например должны поставить на Луну/Марс запас кислорода для купола, под которым живут люди — там будет речь идти об очень жестких сроках и некотором их запасе (если это не аварийная доставка, то запас должен быть, вопрос какой), а вот в случае провала всех сроков — скорее всего виновник станет причиной гибели людей. Грамотное руководство например должно рассчитывать минимум 2-3 кратный запас таких вещей, но ведь бывают и аварии с утечкой.
Что будет делать руководитель из примера в статье в этом случае?
В общем без конкретики задания такой вопрос (из статьи) можно решить только «для общего случая», а лучше всего начать задавать интервьюеру наводящие вопросы о сути задания — иногда именно этого они и ждут.
Т.е. если вы кинулись отвечать на задачу с неполными данными и дали не верный ответ — вы не пригодны. Если начали задавать нужные вопросы, но ответ был дан не совсем верно — могут взять помощником, а потом посмотреть/обучить/… и тд и тп
Т.е. если вы кинулись отвечать на задачу с неполными данными и дали не верный ответ — вы не пригодны. Если начали задавать нужные вопросы, но ответ был дан не совсем верно — могут взять помощником, а потом посмотреть/обучить/… и тд и тп
Да, сейчас я придерживаюсь такой же точки зрения. Надо было устроить диалог.
Вот кстати чего не хватает многим зафейленым краудфандинговым проектам (если там не было злого умысла изначально) — вовремя понять что «что-то не так» и попытаться выйти из ямы наиболее оптимальным и менее затратным для конечных пользователей способом.
А уж скрывать от конечного заказчика явный фейл со сроками или качеством получаемого результата — подписывать «смертный приговор» своей репутации, а иногда и фирме — могут неустойками или возмещением ущерба разорить до банкротства…
Иногда лучше заранее предупредить заказчика что не успеваете/не можете обеспечить требуемое. А дальше решать что можно сделать с этим совместно — или вам дадут доп. сроки (если ему не горит) или вам выделят доп. средства (для найма добавочных специалистов, но когда сроки горят) или вы отдадите всё, что успели сделать заказчику получив хоть какую-то оплату (за вычетом неустоек).
Это всяко лучше, чем до последнего дня говорить что всё будет сделано в срок, а потом «пропасть» со связи или сдать неготовое/непригодное к использованию…
Иногда от результата вашего труда могут зависеть другие проекты (как в примере с аэропортом) и если у заказчика будет время сманеврировать (добавить финансов/нанять другую фирму/...) скорее всего репрессии по отношению к вашей фирме будут значительно меньшие (в идеальном случае вообще отсутствовать), чем в случае полного фейла в последний день…
А уж скрывать от конечного заказчика явный фейл со сроками или качеством получаемого результата — подписывать «смертный приговор» своей репутации, а иногда и фирме — могут неустойками или возмещением ущерба разорить до банкротства…
Иногда лучше заранее предупредить заказчика что не успеваете/не можете обеспечить требуемое. А дальше решать что можно сделать с этим совместно — или вам дадут доп. сроки (если ему не горит) или вам выделят доп. средства (для найма добавочных специалистов, но когда сроки горят) или вы отдадите всё, что успели сделать заказчику получив хоть какую-то оплату (за вычетом неустоек).
Это всяко лучше, чем до последнего дня говорить что всё будет сделано в срок, а потом «пропасть» со связи или сдать неготовое/непригодное к использованию…
Иногда от результата вашего труда могут зависеть другие проекты (как в примере с аэропортом) и если у заказчика будет время сманеврировать (добавить финансов/нанять другую фирму/...) скорее всего репрессии по отношению к вашей фирме будут значительно меньшие (в идеальном случае вообще отсутствовать), чем в случае полного фейла в последний день…
ИМХО выявление подобной проблемы на этапе «опытной эксплуатации» говорит о фундаментальных проблемах в компании.
Скорее всего было немного не так, вероятно проблема в том, что ни виноват никто. Т.е. никто так и не взял на себя ответственность за проект, и это скорее роль ПМ.
А было, думается, так. Продажник облизывал клиента и говорил все можем и даром, и быстро. По дороге от продаж к архитектуре некоторые требования, то забывались, то вплывали. Проблемы были отложены на потом. Отдел продаж давил на архитектора в сроках и намеренно сглаживал острые углы фразами ну это мы обсудим позже или выкинем( примерно как в истории про красные линии ). Архитектор прогнулся. Потом была гонка со временем и выплывание забытых фич, все обрастало костылями, ближе к концу проекта архитектор по ночам крутил и вертел эту конструкцию заляпывая, что отложили на потом. В определенный момент конструкция теряла прочность и начинала сыпаться. Техлид получал требования в разнобой параллельно с поддержкой и багофиксом, как результат в них утонул и утерял общую конструкцию из виду, а может и видел ее совсем по другому. При этом задачи сваливался ну вот прямо сейчас надо фиксить, как результат проект плыл туда где проще и костыльнее код, а не туда куда правил архитектор.
Вышло, что вышло.
Заказчика прогибать на функционал, остальное подпереть костылями, больше никогда так не делать, но боюсь будет именно так.
ИМХО провал концепции ввяжемся разберемся, плюс недостаточная компетенция участников( а может и не достаточная воля ), часто такое можно видит когда разработка идет от продаж и им же курируется. Вот здесь нужна прокладка из очень жесткого и квалифицированного ПМ'а, который не позволить забыть, отложить на потом или продавить. И я полагаю все участники проекта видели куда плывем, но никто не взял на себя ответственность это озвучить. Продажники рассчитывали, авось разгребем и кормили клиента обещаниями, архитектор, «я боюсь об этом думать», тимлид, это не мое дело, будут требования будет код, а у нас аджайл и дальше двух недель мы не смотрим, директор, ну я тут по делам отойду вы уж решите этот вопрос между собой, но если, что обязательно меня в копию, хотя я и не читаю.
Скорее всего было немного не так, вероятно проблема в том, что ни виноват никто. Т.е. никто так и не взял на себя ответственность за проект, и это скорее роль ПМ.
А было, думается, так. Продажник облизывал клиента и говорил все можем и даром, и быстро. По дороге от продаж к архитектуре некоторые требования, то забывались, то вплывали. Проблемы были отложены на потом. Отдел продаж давил на архитектора в сроках и намеренно сглаживал острые углы фразами ну это мы обсудим позже или выкинем( примерно как в истории про красные линии ). Архитектор прогнулся. Потом была гонка со временем и выплывание забытых фич, все обрастало костылями, ближе к концу проекта архитектор по ночам крутил и вертел эту конструкцию заляпывая, что отложили на потом. В определенный момент конструкция теряла прочность и начинала сыпаться. Техлид получал требования в разнобой параллельно с поддержкой и багофиксом, как результат в них утонул и утерял общую конструкцию из виду, а может и видел ее совсем по другому. При этом задачи сваливался ну вот прямо сейчас надо фиксить, как результат проект плыл туда где проще и костыльнее код, а не туда куда правил архитектор.
Вышло, что вышло.
Заказчика прогибать на функционал, остальное подпереть костылями, больше никогда так не делать, но боюсь будет именно так.
ИМХО провал концепции ввяжемся разберемся, плюс недостаточная компетенция участников( а может и не достаточная воля ), часто такое можно видит когда разработка идет от продаж и им же курируется. Вот здесь нужна прокладка из очень жесткого и квалифицированного ПМ'а, который не позволить забыть, отложить на потом или продавить. И я полагаю все участники проекта видели куда плывем, но никто не взял на себя ответственность это озвучить. Продажники рассчитывали, авось разгребем и кормили клиента обещаниями, архитектор, «я боюсь об этом думать», тимлид, это не мое дело, будут требования будет код, а у нас аджайл и дальше двух недель мы не смотрим, директор, ну я тут по делам отойду вы уж решите этот вопрос между собой, но если, что обязательно меня в копию, хотя я и не читаю.
Хм. Ситуация понятная. В подобном довелось участвовать только со стороны разработчика, но описано очень жизненно, как при этом ПМ юлил и выёживался у заказчика. Ну и как мы относимся к коду :)
> Продажник облизывал клиента и говорил все можем и даром, и быстро. По дороге от продаж к архитектуре некоторые требования, то забывались, то вплывали. Проблемы были отложены на потом.
Была не очень давно история где-то в байках на эту тему…
Про то, что менеджер пообещал «за три ночи и три дня» когда реальный срок был существенно выше или требовал большего кол-ва разработчиков, принял на исполнение, а потом сначала предлагал, а потом навязывал разрабу эти сроки с этим проектом, а потом на совещании менеджер огрёб по полной — проект был доделан за счёт этого менеджера — начальник прочитал логи переписки разраба и менеджера и встал на сторону разраба…
К сожалению сходу не могу найти, но может кто-то вспомнит.
Была не очень давно история где-то в байках на эту тему…
Про то, что менеджер пообещал «за три ночи и три дня» когда реальный срок был существенно выше или требовал большего кол-ва разработчиков, принял на исполнение, а потом сначала предлагал, а потом навязывал разрабу эти сроки с этим проектом, а потом на совещании менеджер огрёб по полной — проект был доделан за счёт этого менеджера — начальник прочитал логи переписки разраба и менеджера и встал на сторону разраба…
К сожалению сходу не могу найти, но может кто-то вспомнит.
Не знаю, как бы поступил с мелким проектом, возможно они прощают ошибки, но функциональный разрыв (functional gap) в 20% на проекте в десятки человеко-лет не лечится никак: в лучшем случае банкротство, в худшем — уголовное дело. Если директор проекта узнает об этом за месяц до подписания актов, то он — либо введенное в заблуждение подставное лицо, либо его задачей является осознанное сокрытие хищения денежных средств.
Интересующиеся новостями петербуржцы могут наблюдать последние несколько недель очень похожую картину в городских новостях: шла приёмка СИЗО «Новые Кресты», подписали акты, выявили оцененные в приблизительно 10% от суммы заказа functional gap, произошло заказное убийство и все заверте…
Интересующиеся новостями петербуржцы могут наблюдать последние несколько недель очень похожую картину в городских новостях: шла приёмка СИЗО «Новые Кресты», подписали акты, выявили оцененные в приблизительно 10% от суммы заказа functional gap, произошло заказное убийство и все заверте…
Какая-то очень странная и ситуация и выводы, слишком много вопросов возникает:
1) Я не настаиваю, но весьма криво выглядит ситуация, когда деньги распределяются из единственного внешнего заказа, без страховки (не оставить на чёрный день, не имея дополнительных паралельных источников).
Это странно!
2) Прожект менеджера, я так понимаю или просто нет, или уборщица по совместительству.
Кому сгружались данные на этапах каждого месяца квартала? Кто видел, что его квартал за кварталом кормят завтраками и ничего не предпринимал? Кто поверил словам разработчиков настолько, что перестал держать руку на пульсе и не считал, как с каждым днём, шансы сделать в срок скатывались в отрицательную зону?
3) Если должностное лицо, общающееся с заказчиком видело хотя бы за квартал, полгода, что проект медленно натягивается на глобус и никак не стал передоговариваться с заказчиком, то этот человек должен занять очередь на натягивание себя на глобус.
Можно хаить архитекторов, можно хаить техлидов, если они врали насчёт реального положения дел, то их стоит дауншифтить, если они говорили как есть, то тот кому они говорили всё как есть, прос… ал сам проект, пока видится проблема в руководстве, прокутившее где-то по кабакам, не следя за исполнением заказа.
Во всяком случае, неожиданностью 20% недоделок в последний день быть просто не может, об этом все знают заранее.
1) Я не настаиваю, но весьма криво выглядит ситуация, когда деньги распределяются из единственного внешнего заказа, без страховки (не оставить на чёрный день, не имея дополнительных паралельных источников).
Это странно!
2) Прожект менеджера, я так понимаю или просто нет, или уборщица по совместительству.
Кому сгружались данные на этапах каждого месяца квартала? Кто видел, что его квартал за кварталом кормят завтраками и ничего не предпринимал? Кто поверил словам разработчиков настолько, что перестал держать руку на пульсе и не считал, как с каждым днём, шансы сделать в срок скатывались в отрицательную зону?
3) Если должностное лицо, общающееся с заказчиком видело хотя бы за квартал, полгода, что проект медленно натягивается на глобус и никак не стал передоговариваться с заказчиком, то этот человек должен занять очередь на натягивание себя на глобус.
Можно хаить архитекторов, можно хаить техлидов, если они врали насчёт реального положения дел, то их стоит дауншифтить, если они говорили как есть, то тот кому они говорили всё как есть, прос… ал сам проект, пока видится проблема в руководстве, прокутившее где-то по кабакам, не следя за исполнением заказа.
Во всяком случае, неожиданностью 20% недоделок в последний день быть просто не может, об этом все знают заранее.
Гипотетические проекты с факапом в финальной стадии #comment_10126724
Сильно гипотетики, да.
2,3,4 в которой опять ни техлид, ни архитектор не при чём.
ПМ и вся бригада профукала этапы общения со внешними звеньями,
4) договариваться год о встрече? если встреча такого масштаба, то она важна всем сторонам.
Если там единственный приглашённый владелец, и он просто не приезжает, то ему это не нужно было с самого начала. Если масштаб потерь серьёзный, то риски оговариваются обеими сторонами, можно либо договорится для подстарховки «спикерами от владельца такого-то». В крайнем случае обговорить/огранизовать онлайн встречу (видеофонию), не в последние же 5 минут оказывается, что человек не доступен на планете!
3) Взять у заказчика контракт на подготовку к несуществующему железу, и не обговорить, что если железо не выйдет на рынок, то и игра не взлетит? ну-ну.
2) то же, что и предыдущий пункт. Только тут риски как минимум пополам делятся, за год не получить средств интеграции, это опять должен быть либо совсем мегаогромный проект, и год — не срок, либо очень хилый менеджмент, оставивший на самотёк самый рисковый этап на конец срока исполнения.
1) об ИИ тоже не надо думать как о магии, математика она и есть математика, она как минимум будет работать, на 20% будет недорабатывать математика? есть над чем склонить голову.
В общем примеры и правда надуманные, к исходной ситуации, описанной в статье они вряд-ли имеют хоть какое-то отношение.
Любые риски внешних факторов при обсуждении заказа фиксируются, и по ним обычно формируется группа, отслеживающая эти риски, тянуть до срока сдачи нет никакого желания ни у кого, потому что абсолютно все держат на кону деньги.
Либо просто организованное кидалово, но это уже грязь, которую обсуждать нет желания.
2,3,4 в которой опять ни техлид, ни архитектор не при чём.
ПМ и вся бригада профукала этапы общения со внешними звеньями,
4) договариваться год о встрече? если встреча такого масштаба, то она важна всем сторонам.
Если там единственный приглашённый владелец, и он просто не приезжает, то ему это не нужно было с самого начала. Если масштаб потерь серьёзный, то риски оговариваются обеими сторонами, можно либо договорится для подстарховки «спикерами от владельца такого-то». В крайнем случае обговорить/огранизовать онлайн встречу (видеофонию), не в последние же 5 минут оказывается, что человек не доступен на планете!
3) Взять у заказчика контракт на подготовку к несуществующему железу, и не обговорить, что если железо не выйдет на рынок, то и игра не взлетит? ну-ну.
2) то же, что и предыдущий пункт. Только тут риски как минимум пополам делятся, за год не получить средств интеграции, это опять должен быть либо совсем мегаогромный проект, и год — не срок, либо очень хилый менеджмент, оставивший на самотёк самый рисковый этап на конец срока исполнения.
1) об ИИ тоже не надо думать как о магии, математика она и есть математика, она как минимум будет работать, на 20% будет недорабатывать математика? есть над чем склонить голову.
В общем примеры и правда надуманные, к исходной ситуации, описанной в статье они вряд-ли имеют хоть какое-то отношение.
Любые риски внешних факторов при обсуждении заказа фиксируются, и по ним обычно формируется группа, отслеживающая эти риски, тянуть до срока сдачи нет никакого желания ни у кого, потому что абсолютно все держат на кону деньги.
Либо просто организованное кидалово, но это уже грязь, которую обсуждать нет желания.
Ну из относительно близких к реальности примеров к интеграции —
в проекте всё завязано на микросхему, выпускаемую в Китае крупным заводом.
К моменту сдачи заказа оказывается что завод месяц как перестал её выпускать, на складе осталось 100шт (а надо как минимум 1000), ради 900 шт завод перезапускать линию не будет, переделывать под другую м/с слишком дорого/сложно/…
Но и тут есть фейл со стороны разраба.
Если были уверены что проект будет именно на этой м/с, то должны были или закупить сами заранее или договориться о такой закупке с заказчиком заранее (если это его часть ответственности), а уже потом приступать к основной части проектирования.
Причем закупить лучше с хорошим запасом(если позволяет цена с многократным).
в проекте всё завязано на микросхему, выпускаемую в Китае крупным заводом.
К моменту сдачи заказа оказывается что завод месяц как перестал её выпускать, на складе осталось 100шт (а надо как минимум 1000), ради 900 шт завод перезапускать линию не будет, переделывать под другую м/с слишком дорого/сложно/…
Но и тут есть фейл со стороны разраба.
Если были уверены что проект будет именно на этой м/с, то должны были или закупить сами заранее или договориться о такой закупке с заказчиком заранее (если это его часть ответственности), а уже потом приступать к основной части проектирования.
Причем закупить лучше с хорошим запасом(если позволяет цена с многократным).
А так, отвечая именно на вопрос собеседования, наверно стоит собрать команду заново,
оценить какие учтённые и неучтённые риски привели к таким результатам,
просчитать объём работ по устранению недоделок,
пересчитать риски по каждому спектру работ,
назначить на каждый риск ответственного (не важно сколько их, даже если 1 человек будет ответственный, но со стальными шарами),
пересчитать необходимые сроки для разрешения недоделок,
послать результаты расчётов переговорщику с заказчиком, всё по результатом совещаний высказать, после провала лучше побыть честным,
Если заказчик согласится на доделки, то приступать к работе,
каждую неделю ( а в дисциплинарных мерах «за заслуги» можно и раз в день ), спрашивать прогресс по каждому спектру работ.
И искать следующие проекты, перераспределить команду так, чтобы можно было вести больше 1-го проекта одновременно, Если плавно распределять не получается, просто разделить людей пополам, на команду А и Б, всё равно коммуникация между командами и взаимопомощь останется.
Если хочется оставить компанию на плаву, можно и перекредитоваться, технари всё не владельцы бизнеса, денежные вопросы не должны отвлекать от работы.
оценить какие учтённые и неучтённые риски привели к таким результатам,
просчитать объём работ по устранению недоделок,
пересчитать риски по каждому спектру работ,
назначить на каждый риск ответственного (не важно сколько их, даже если 1 человек будет ответственный, но со стальными шарами),
пересчитать необходимые сроки для разрешения недоделок,
послать результаты расчётов переговорщику с заказчиком, всё по результатом совещаний высказать, после провала лучше побыть честным,
Если заказчик согласится на доделки, то приступать к работе,
каждую неделю ( а в дисциплинарных мерах «за заслуги» можно и раз в день ), спрашивать прогресс по каждому спектру работ.
И искать следующие проекты, перераспределить команду так, чтобы можно было вести больше 1-го проекта одновременно, Если плавно распределять не получается, просто разделить людей пополам, на команду А и Б, всё равно коммуникация между командами и взаимопомощь останется.
Если хочется оставить компанию на плаву, можно и перекредитоваться, технари всё не владельцы бизнеса, денежные вопросы не должны отвлекать от работы.
Не забываем что «на последние 10% объёма задачи нужно будет потратить 90% времени».
Финал 5й: допустим, что проект готов на все 100%, и деньги все потрачены. — Увольняем всех, т.к. других заказов в запасе всё-равно нет(по условиям кейса), а значит любая концовка смертельна.
Выводы: нужно всегда иметь в запасе несколько проектов, которые могут перекрыть.
Выводы: нужно всегда иметь в запасе несколько проектов, которые могут перекрыть.
Насколько я понимаю, почти любой сценарий выльется в вопросы заказчика, и итоге в обозначенную некомпетентность всех уровней в компании, каждая из которых должна была заложить свои риски. Если случилась такая ситуация, значит профакапились все уровни, от разработки до проектного отдела. По репутации компании будет сильный удар.
Если текущего состояния проекта достаточно для введения в коммерческую эксплуатацию, можно отдать продукт в коммерцию, и постепенно закрывать хвосты за счет компании, т.е. за свой счет. Так репутация пострадает не сильно, команда не уйдет, и в итоге проект будет сдан.
Можно выбить время путем обсуждения ТЗ (всегда есть что можно улучшить, ошибки в ТЗ, и прочее), пакетов доработок которые можно внедрить сейчас, импрувы продукта которые непременно нужны на старте в коммерции, и далее цикл согласования. Если проект действительно крупный, это может дать нужное время команде на закрытие хвостов. Работа команды оплачивается за свой счет. Так репутация не пострадает (возможно, даже выростет, мол побеспокоились о продукте, помогли, сделали лучше чем нужно), команда не уйдет, и продукт будет сдан в срок (новый, согласованный).
Если уже совсем край, дедлайн прямо завтра, тогда ничего не остается, кроме как посыпать голову пеплом, проанализировать текущее состояние, сделать переоценку, заложить риски, согласовать. Это будет менее болезненно. Дальнейшая доработка за свой счет.
Отвечал чисто на вопрос из заголовка статьи, из интереса верное ли мышление (не являюсь руководителем отдела разработки). Комментарии и статью предварительно не читал.
Такие решения приемлемы?
Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново.
Бред какой-то…
- Как клиент умудрился оплатить 80% функционала 100% денег ?
- Как умудрились подписать котракт не имея критериев приемки ?
- Как умудрились разрабатывать и дизайнить не имея критериев приемки?
- Как умудрились найти ПМ который не предусмотрел риски для таких бюджетов?
Это какие юристы ИТ компании пропустили такой бред на подпись ?!
Формально — проблема Подрядчика. Я бы на месте клиента еще и неустойку вытряс :)
Архитектор — не думаю что он виноват. Обычно роль архитектора такие косяки предовращать и видеть «вперед» «до финала», он же с упреждением работает.
Код не его проблема.
Вопрос откуда и в какой момент вылезли эти 20% и как их оценили? Если ПМ адекватный то можно и на Change Request / доп соглашение опираться…
Архитектор — не думаю что он виноват. Обычно роль архитектора такие косяки предовращать и видеть «вперед» «до финала», он же с упреждением работает.
Код не его проблема.
Вопрос откуда и в какой момент вылезли эти 20% и как их оценили? Если ПМ адекватный то можно и на Change Request / доп соглашение опираться…
И если оплачено 100% по актам приемки с 80% функционала без указания перечня дефектов то… проект успешен. Нет проблемы :))))
Как клиент умудрился оплатить 80% функционала 100% денег ?
Вы возможно будете смеяться — но в самолётостроении такое происходит уже лет 20 — во всех странах: у нас, всех америках, европе, азии — в гражданском секторе… В военном и 200% у всех-всех на планете не выгядит чем-то чересчур. Да и полные провалы с отменой заказов на уже полетевшее — не такая уж редкость (чаще маскируют сверхмалой штучной серией 3-5 бортов, что бы не выглядело совсем уже попилом, при том что это не распил-откат, а честные технические провалы — не срослись характеристики реальные с многажды правленным ТЗ.)
Это я понимаю. Есть юридические механизмы, позволяющие передать всю сумму денег за частичный результат. Но на это делается соотсветсвующая юридическая бумажка, закрывающая будущие взаимные претензии обеих сторон.
И опять же, это не приводит к состоянию «уволить архитектора», при нормальном развтии событий.
И опять же, это не приводит к состоянию «уволить архитектора», при нормальном развтии событий.
В таких проектах это всё обычно предусматривается в первую очередь в документах. Или повышенной ценой проекта (что бы в случае провала 1 из 10 компания не закрывалась) или повышенной ценой риска проекта «мы будем работать почти без прибыли, но результат не гарантируем» (такое часто в оборонке — предприятия на гос. обеспечении, получают за заказы только себестоимость + самую минимальную прибыль).
Опять же в приведенных вами ситуациях нет 100% провала — часть денег «вернется» найденными техническими решениями, которые будут использованы в других проектах.
Часть проектов можно доделать за разумные средства в разумные сроки.
Или дождаться выхода новых технологий/материалов/аппаратуры/… и доделать проект…
Или где-то можно изменить ТТХ до приемлимого обоими сторонами.
100% провальный проект только или в случае злого умысла или от полной некомпетентности или всей команды или отдельных ее членов.
Например согласиться строить танк весом в 1000 тонн, который должен будет ездить по обычной почве в отсутствии работающей технологии антигравитации скорее всего будет или явным попилом/диверсией или разрабами, которые ничего не понимают в своей области…
Опять же в приведенных вами ситуациях нет 100% провала — часть денег «вернется» найденными техническими решениями, которые будут использованы в других проектах.
Часть проектов можно доделать за разумные средства в разумные сроки.
Или дождаться выхода новых технологий/материалов/аппаратуры/… и доделать проект…
Или где-то можно изменить ТТХ до приемлимого обоими сторонами.
100% провальный проект только или в случае злого умысла или от полной некомпетентности или всей команды или отдельных ее членов.
Например согласиться строить танк весом в 1000 тонн, который должен будет ездить по обычной почве в отсутствии работающей технологии антигравитации скорее всего будет или явным попилом/диверсией или разрабами, которые ничего не понимают в своей области…
НЛО прилетело и опубликовало эту надпись здесь
после прочтения сложилось ощущение, что не все на своих местах работают.
Ну, я точно на месте лидера тогда был бы не на своём месте. Даже сейчас не уверен.
Сомнения в себе не лучшие качества лидера) А по данной тебе, думаю, что это был вопрос помогающий определить ваш градус ответственности и уверенности в своей компетенции. Отвечать следовало примерно так:
1. Говорим, что с вами этого бы не случилось, т.к. задача тех.лида ещё на старте предусмотреть возможные грабли и подобрать правильную методологию разработки. Гнать на архитектора не вариант, вы отвечаете за команду, весь спрос с вас. Если обстоятельства не от вас зависят, то спрос с вас никуда не деется, а линь нивелируется вашей способностью решать подобные ситуации.
2. Раз уж проблема выявлена и пошла пьянка, то просим уточнения для описания проекта. Есть Показываем, что разбираемся в системах (complex/complicated). В одном из случаев возможна частичная отгрузка с продолжением разработки. На израсходованный бюджет отвечаем, что этот риск был заложен в стоимость разработки. Однако прежде чем использовать выручку своей фирмы для доделки, говорим, что готовы обсудить с заказчиком возникшую проблему и найти совместное решение. Серьезные заказчики, всегда подстраховываются и предусматривают, что разработка может не быть закончена в срок, неустойка никому не на руку — софт нужно будет обслуживать.
Итого вы должны были показать, что: уверены в себе, понимаете бизнес-процессы выше вас, готовы частично совмещать в себе обязанности менеджера проекта, умеете признавать ошибки и не боитесь браться за их решение, и главное — не перебрасываете ответственность на подчиненных, даже если это их косяк.
Если после не дают конкретный кейс, то на этом ответ можно считать оконченым.
1. Говорим, что с вами этого бы не случилось, т.к. задача тех.лида ещё на старте предусмотреть возможные грабли и подобрать правильную методологию разработки. Гнать на архитектора не вариант, вы отвечаете за команду, весь спрос с вас. Если обстоятельства не от вас зависят, то спрос с вас никуда не деется, а линь нивелируется вашей способностью решать подобные ситуации.
2. Раз уж проблема выявлена и пошла пьянка, то просим уточнения для описания проекта. Есть Показываем, что разбираемся в системах (complex/complicated). В одном из случаев возможна частичная отгрузка с продолжением разработки. На израсходованный бюджет отвечаем, что этот риск был заложен в стоимость разработки. Однако прежде чем использовать выручку своей фирмы для доделки, говорим, что готовы обсудить с заказчиком возникшую проблему и найти совместное решение. Серьезные заказчики, всегда подстраховываются и предусматривают, что разработка может не быть закончена в срок, неустойка никому не на руку — софт нужно будет обслуживать.
Итого вы должны были показать, что: уверены в себе, понимаете бизнес-процессы выше вас, готовы частично совмещать в себе обязанности менеджера проекта, умеете признавать ошибки и не боитесь браться за их решение, и главное — не перебрасываете ответственность на подчиненных, даже если это их косяк.
Если после не дают конкретный кейс, то на этом ответ можно считать оконченым.
Сидел на реализации одного проекта (не в области ИТ, в области нефтепереработки). Задача была не аналогичная, но принцип похожий — у Заказчика свое видение функционала, к ТЗ припаркован талмуд «хотелок», которы продажники взяли и принайтовали к договору, у исполнителей-субподрядчиков свое видение, основанное только на ТЗ в обрезанной немного версии, у меня — субподрядчик с четким договором, шесть исполнителей под рукой на оставшуюся работу, мнение директора что «Заказчик должен быть доволен», и тоска в глазах… Решение было единственное — на что то согласиться (доработать необходимые работы напильником), где-то Заказчика притоптать, сославшись на нестыковки ТЗ и «хотелок», где-то притоптать субподрядчика, сославшись на достигнутые договоренности и принципы «честного бизнеса» — утопят нас мы утопим вас. В итоге Заказчик получил то что ему было нужно, директор не потерял денег и получил свою прибыль, подрядчики тоже сработали неплохо, из минусов — отрицательная репутация моя у директора, т.к. цейнот был у меня, а у директора были жалобы от Заказчика и субподрядчика на мою слишком сильную инициативу.
Печальная история о том, что в команде проекта нет человека, который лично, своей задницей, отвечает за превращение оценки в человеко-часах в сроки на календаре.
Пока такого человека не появится, пока он не взвалит на себя тяжкий труд разбираться в каждой конкретной ситуации в магии таких преобразований — фейлы будут вас преследовать на каждом проекте.
Программист дает оценку задач. И отвечает за свою оценку в разумных пределах.
Тим-лид? Дает сводную оценку трудозатрат и рисков. И отвечает за эту оценку.
Сроки? Это не сюда, это к тем, кто работает с заказчиком. Программист не должен ничего знать о сроках. Его задача — сделать задачу, оцененную в 2 часа, не более, чем за 3 часа. Грубо говоря ))
Пока такого человека не появится, пока он не взвалит на себя тяжкий труд разбираться в каждой конкретной ситуации в магии таких преобразований — фейлы будут вас преследовать на каждом проекте.
Программист дает оценку задач. И отвечает за свою оценку в разумных пределах.
Тим-лид? Дает сводную оценку трудозатрат и рисков. И отвечает за эту оценку.
Сроки? Это не сюда, это к тем, кто работает с заказчиком. Программист не должен ничего знать о сроках. Его задача — сделать задачу, оцененную в 2 часа, не более, чем за 3 часа. Грубо говоря ))
кажется немного сумбурно получилось, но идея отталкиваться от команды в целом и уважать более опытных — кажется вполне разумной.
Не так страшны первые 80% проекта, как вторые 80%
Не понял, а куда прибыль потрачена? 100% оплачено — это ведь не только зарплата разработчиков и уборщицы вместе с тим-лидом. Или руководитель проекта уже уехал на море и потратил весь бюджет на профурсеток, не закончив работу…
Интересная ситуация в комментариях наблюдается
Часть обратила внимание на потраченные 100% при невыполненной работе, типа вот ведь разгильдяи, вруны, распильщики, некомпетентность на всех уровнях. Даже смертную казнь упомянули и кровавые расправы.
Часть обратила внимание что через год обнаружилась фатальная несовместимость решения.
Я во второй половине. Обдумывая вопрос я никак не мог принять первый кейс, потому что он не укладывается в моё мировозрение. Я сосредоточился не на финансах (как заметил Calc — это не дело тим лида — и я поддерживаю, тем более что в то время я вообще с финансами компании ни разу не работал, знал только в общих чертах).
Предполагал первопричину промахов в неудачной организации работы команды, спрашивал про методику работы, про предварительную приёмку.
Ещё раз хотел бы отметить, что это вопрос с собеседования, то есть ситуация вымышленная. Задача, проверяющая ход мыслей и наличие определённого набора soft-skills. На тот момент у меня не было некоторых из них. Например, тогда я ещё не общался с заказчиками напрямую. Сейчас я просил бы моего оппонента на собеседовании принять роль заказчика в этой игровой ситуации, чтобы выяснить его мнение как заказчика. Как он отреагировал бы на правду про 20%, что он вообще думает про откладывание частей работы «на потом», готов ли он запустить частично работающий проект. Заказчик в данном случае тоже часть команды и с ним тоже надо общаться.
Дополнительно ко всему, сейчас я бы ещё на стадии собеседования принял факт, что это УЖЕ МОЙ ПРОЕКТ. Так сказать, проникся к нему душой, мысленно прожил бы его целый год. И рассматривал его как кейс, на котором надо научиться и который нужно предотвратить в будущем. И как сказал fastwit — задокументировал его для себя, для каждого в команде и даже для заказчика :)
На ум приходит история
Один маклер продул на бирже миллион баксов. Пришёл с повинной головой, рассказал боссу как всё было, в чём именно он ошибся. Предложил уволить его. Обещал вернуть частями.
Босс сказал: «Вы только что получили образование за счёт компании. Ваша учёба стоила нам 1 000 000 долларов. Идите, работайте, применяйте полученные знания на практике.»
Часть обратила внимание на потраченные 100% при невыполненной работе, типа вот ведь разгильдяи, вруны, распильщики, некомпетентность на всех уровнях. Даже смертную казнь упомянули и кровавые расправы.
Часть обратила внимание что через год обнаружилась фатальная несовместимость решения.
Неправдоподобно. Там с первых строк прям ультра-косяк продакт-менеджера — тянул до последнего. Даже при ватерфлоу так запускать не получалось никогда, а уже при agile и не получится.
Я во второй половине. Обдумывая вопрос я никак не мог принять первый кейс, потому что он не укладывается в моё мировозрение. Я сосредоточился не на финансах (как заметил Calc — это не дело тим лида — и я поддерживаю, тем более что в то время я вообще с финансами компании ни разу не работал, знал только в общих чертах).
Предполагал первопричину промахов в неудачной организации работы команды, спрашивал про методику работы, про предварительную приёмку.
Ещё раз хотел бы отметить, что это вопрос с собеседования, то есть ситуация вымышленная. Задача, проверяющая ход мыслей и наличие определённого набора soft-skills. На тот момент у меня не было некоторых из них. Например, тогда я ещё не общался с заказчиками напрямую. Сейчас я просил бы моего оппонента на собеседовании принять роль заказчика в этой игровой ситуации, чтобы выяснить его мнение как заказчика. Как он отреагировал бы на правду про 20%, что он вообще думает про откладывание частей работы «на потом», готов ли он запустить частично работающий проект. Заказчик в данном случае тоже часть команды и с ним тоже надо общаться.
Дополнительно ко всему, сейчас я бы ещё на стадии собеседования принял факт, что это УЖЕ МОЙ ПРОЕКТ. Так сказать, проникся к нему душой, мысленно прожил бы его целый год. И рассматривал его как кейс, на котором надо научиться и который нужно предотвратить в будущем. И как сказал fastwit — задокументировал его для себя, для каждого в команде и даже для заказчика :)
На ум приходит история
Один маклер продул на бирже миллион баксов. Пришёл с повинной головой, рассказал боссу как всё было, в чём именно он ошибся. Предложил уволить его. Обещал вернуть частями.
Босс сказал: «Вы только что получили образование за счёт компании. Ваша учёба стоила нам 1 000 000 долларов. Идите, работайте, применяйте полученные знания на практике.»
> «Вы только что получили образование за счёт компании. Ваша учёба стоила нам 1 000 000 долларов. Идите, работайте, применяйте полученные знания на практике.»
не лучший пример.
нет чёткого ответа была ли от менеджера положительная прибыль для компании и сколько раз, на каких суммах и какой % прибыли.
Если ему просто доверили 1кк и он их «продул» то виноват в 1ю очередь доверивший такую сумму человеку без опыта.
Если же у него был «рост», сначала доверяли по 20-30к, потом 100к, потом 500…
все работы были в "+", то дальше надо считать — возможно его предыдущая работа покрыла своей прибылью этот фейл, или близка к нему — тогда ответ начальника верный.
В общем снова нет конкретики.
не лучший пример.
нет чёткого ответа была ли от менеджера положительная прибыль для компании и сколько раз, на каких суммах и какой % прибыли.
Если ему просто доверили 1кк и он их «продул» то виноват в 1ю очередь доверивший такую сумму человеку без опыта.
Если же у него был «рост», сначала доверяли по 20-30к, потом 100к, потом 500…
все работы были в "+", то дальше надо считать — возможно его предыдущая работа покрыла своей прибылью этот фейл, или близка к нему — тогда ответ начальника верный.
В общем снова нет конкретики.
НЛО прилетело и опубликовало эту надпись здесь
Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново. Я, как кандидат на руководителя разработки, должен проанализировать ситуацию, принять решение, согласовать с заказчиком.
Так как это собеседование и ситуация гипотетическая, причём с не полной информацией, то надо показать как Вы умеете:
1) анализировать ситуацию
2) принимать решения
3) согласовывать с заказчиком
Так как по ситуации задана не полная информация, то надо её дополнить выгодными для Вас данными. Например исходя из того что компания занимается «разработкой программного обеспечения для веб и для мобильных приложений». Предположить что заказчик заказал сайт. А сайт можно уже запустить на восьмидесяти процентах функционала и в дальнейшем заказчик захочет чтобы его сопровождали и дорабатывали. А для сайта можно постепенно переводить сайт на новую архитектуру и доработать функционал до требуемого.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вопрос с собеседования тим-лида: что делать, если деньги на проект получены и истрачены, а проект не готов