Позиция: руководитель группы разработки, team-leader, технический лидер в компании, занимающейся разработкой программного обеспечения для веб и для мобильных приложений.
Ситуация: команда получает проект, довольно длинный по времени. С заказчиком составили техническое задание, график выполнения и договорились о постепенной оплате работы. Скажем план на год, а заказчик будет делать оплату 4 раза, каждый квартал.
Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново. Я, как кандидат на руководителя разработки, должен проанализировать ситуацию, принять решение, согласовать с заказчиком.
6 лет назад я был в замешательстве. И сейчас тоже не имею 100% ответа. Мой ответ не устроил тогда. Не знаю, устроит ли сейчас.
Финал первый. Если проект, готовый на 80%, не может быть закончен из-за плохой архитектуры — архитектора уволить или отстранить от этого проекта. Но лучше уволить. Хотя жалко. Но он зациклился на красоте кода. Но получилось не гибко. У него было время, он пытался, но вот такая ситуация. Уволить, назначить другого. Сообщить заказчику, что проект затянулся, нужно дополнительное время и деньги. Мы перепишем заново за ещё один год. Заказчик откажется. Вернуть деньги не сможем. Репутация компании испорчена. Плохие отзывы. Либо вернём деньги, но мы разорены. Все в ж**е. Отматываем кассету с этим фильмом назад, на момент начала финального разговора с заказчиком.
Финал второй. Проект готов на 80%, осталось 20%, больше денег от заказчика нет. Сказать команде, что надо сделать оставшиеся 20% бесплатно. Часть команды уволится, возможно в тот же день. Либо напрягутся и сделают, несмотря на уверения архитектора. Закостылят по-чёрному, напишут ужасные страшные решения, самый вонючий г****код. Заказчик получит своё решение с опозданием на 3 месяца. Репутация сохранена. Компания сохранена. Потеряна часть команды и командный дух. Можно продолжать, но отматываем финал ещё раз.
Финал третий. Выяснить в команде причину, почему 20% не могут быть решены. Заказчику сообщаем, что 20% не могут быть реализованы. Говорим правду, посыпаем себе голову пеплом. «Пытались до самого последнего, но ничего не выходит. Задача не решается программным способом. Целый год искали, найти не смогли. Нужны другие решения. Давайте эти 20% зафейлим, переформулируем, попробуем сделать иначе.» У заказчика почти готовое решение, возможно даже уже в эксплуатации. Он не захочет бросить то, что уже оплатил и чем уже пользуется. Он соглашается зафейлить требования, «зафлексить», переформулировать, продолжить. Репутация сохранена. Команда сохранена. Архитектор поглажен против шерсти, но сохранён. Вроде вышли из ситуации, но... отматываем кассету, теперь на год назад.
Приквел. На самом деле заказчик всегда переплачивает ради вот таких ситуаций. В размер оплаты включен риск, потому что у компании всегда должен быть запас. Если не оплачивает этот заказчик, то оплачивает другой, на другом проекте. Потому что команда всегда врёт при оценке времени, тем более в перспективе на год. Где они дали оценку в день, там будет три дня. Где дали оценку в год, там будет три года. И потому что люди всегда переоценивают свои силы. Потому что заранее не видно подводных камней. Потому что кроме программирования нужен дизайн, и тестирование, и эксплуатация — это большие накладные расходы, которые невозможно подсчитать заранее. Ещё команда может быть задействована не вся, а какая-то часть может сидеть без работы. Они тоже хотят кушать, но делать им пока нечего. На них нужен резерв. На новогодние подарки нужен резерв. На уборщицу нужен резерв.
Поэтому ставка за час иногда тройная. Команды, которые сбивают цены, демпингуют, могут не выжить в описанной ситуации и умереть по окончании какого-нибудь зафейленного проекта, если что-то пошло не так. Или не пережить сезон отпусков. Или не дать новогодний подарок. Или уволить уборщицу. Так что мы уже изначально просим заказчика оплатить все эти накладные расходы и даже этот фейл. И в некоторый момент времени извлекаем запасы и оплачиваем дополнительное время на устранение проблемы 20% за счёт этакого подкожного финансового жира команды. В случае неудачного финала для заказчика есть потеря времени, он просто ждёт, пока мы утихомирим всех наших тараканов, прекратим панику и закончим этот чёртов кусок кода. Но заказчику возможно не придётся доплачивать, а команде не придётся работать бесплатно.
Римейк. Теперь про фейл архитектора. Да. Это его личный фейл. Пусть выпьет водки и погрустит. Через год, ЕСЛИ проект зафейлится, ЕСЛИ он будет уволен, ЕСЛИ команда развалится, ЕСЛИ компания обанкротится. НО мы даже не дойдём до такой ситуации! Потому что мы команда.
Примите факт, что я сейчас даю правильные решения. С того собеседования прошло шесть лет. Сейчас я делюсь опытом и не ошибаюсь.
Прочитал? Принял? Поверил? А теперь я скажу, что ты ошибся. Потому что я тебе соврал. Я не скажу, в чём именно я соврал, но я соврал, а ты поверил. Ты перестроил свой ход мыслей, решив, что теперь он правильный. Но он не правильный. И ты ошибёшься, если будешь пользоваться этим ходом мыслей. Но это такой ход литературный, чтобы вызвать эмоцию. Всё проще. Обыденнее.
Я могу ошибиться. Ты можешь ошибиться. Заказчик мог ошибиться ещё при постановке технического задания. Архитектор мог ошибиться в выборе архитектуры и технологий. Придумать то, что не нужно. Не придумать то, что нужно. И команда разработки может ошибиться — сделать всё как попало, наперекосяк и с багами. Могли ошибиться с оценкой сроков. Могли ошибиться с выбором алгоритмов. Ошибаются все. Правило «век живи — век учись» — актуально. Принцип OpenMind — актуален. Люди ошибаются, и на этом учатся. Лучшие программисты ошибались десятки раз. За идеальной архитектурой прячутся десяток кривых решений. В тщательно скрываемом списке опыта ведущих разработчиков и архитекторов есть гостевая книга на файлах без базы данных, сайты на табличной вёрстке, приложение «Hello, World!» с «segmentation fault».
Но нет отдельно взятого человека, который умнее всех. Нет более умного даже среди команды. Есть чуть более опытный. Он обжёгся и НЕ ДАСТ обжечься другим, ЕСЛИ его спросят. Он выиграл и МОЖЕТ дать совет выигрышной стратегии, ЕСЛИ его спросят. Для этого его надо спросить. Не факт, что более ОПЫТНЫЙ является архитектором, ну то есть принимает решения. Он может быть тестировщиком, который скажет, что ЭТА часть решения чрезвычайно сбойная, потому что в прошлом ему никак не удавалось написать тест на неё. Это может быть спец по поисковой оптимизации, который скажет, что из-за ТАКОГО архитектурного подхода в прошлом у проекта органического трафика не было вообще, поисковая система даже не видела всю красоту, потому что она исключительно RIA, и SPA, и browser-side only. Это может быть админ, который скажет, что ЭТОТ пакет вообще не собирается на Debian 5 + Python 2.27, которые стоят у заказчика на серверах, значит нам придётся писать все алгоритмы самостоятельно, а не пользоваться готовым пакетом.
В той части фильма, которая находится между началом и концом кассеты, которую я быстро промотал — там ДОЛЖНО находиться что-то, что может позволить команде принимать решения совместно, заранее предусматривать ситуации этих нерешаемых 20%. Там архитектор учится. Там каждый учится. Там команда помогает друг другу. Там команда становится опытнее. Её навыки растут.
Но я не знаю точно, как это делается. Я знаю, как я сам наращиваю свои навыки. Знаю, как помочь тем, кто просит помощи по конкретной технологии. Но 100% верного решения нет. Особенно в том, как именно выбрать технологию или область повышения навыков.
К примеру, я за год изучил AngularJS 1, VUE,js 2, Twitter Bootstrap 3, Semantic UI 2, M.E.A.N., Phalcon 3, Yii 2, Laravel 5, Grunt, SCSS. Прокачался так, что голова кружится от ощущения собственной крутоты. Но в решениях компании, где я работаю, эти технологии не используются. Меня разрывает от гордости, а команде ни холодно, ни жарко от моих навыков. Они могли бы спросить меня, какой язык или фреймворк выбрать для нового проекта, вот только выбирать не приходится — мы работаем на одном стеке уже три года, переписывать заново не собираемся. Монопродукт. Были направления или ситуации, в которых команда нуждалась в новых навыках — я же про них не думал, потому что не знал об этой нужде.
Зачем я вообще изучал эти технологии? Хотел и изучал. Чем опытнее становишься, тем проще изучать. У меня это уже непрерывный процесс изучения чего-либо. Мог бы изучить что-либо другое, я вообще открыт к знаниям, мне нравится пробовать и экспериментировать. Вопрос: с чем экспериментировать? Сейчас я вижу, что если бы год назад мне сказали, что в мае будет то, а в сентябре это — я бы подстроился и изучил нужное. А поскольку я выбирал сам, то в какой-то мере ошибся, потому что не спросил команду. В мае был неготов тут, в сентябре был неготов там. Были сложные ситуации и решения принимали уже наобум, как попало, устраняя баги и затыкая дыры вслепую. Еле пережили возможную ситуацию выпадения из органического поиска. Кое-как пережили самостоятельно выращенный DDoS против себя же.
Ещё один момент — рост личных навыков есть, а рост пользы для компании нет. В конце года поднял бы вопрос: пожалуйста, сделайте мне зарплату больше — я вон какой умный стал, умею то и то, вот! Но если бы команда оценивала мой вклад, то про меня решили бы, что я вообще лишнее звено. Что-то постоянно учу, но если что — «это надо изучить дополнительно». Что-то знаю, но в конкретной ситуации ничего сказать не могу. Мои ошибки с выбором технологий — это мой груз.
Долгая неделя размышлений и самокопания. Общение в команде. Консультации с другими командами. Поиск аналогичных ситуаций и решений. Черновой набросок. Вот что получилось: uptlo.com - все идеи проекта на главной странице. Пиарить не буду — не работает почти ничего :) Но думаю, проект пригодился бы командам для совместного повышения навыков в нужном направлении. И если кому-то хочется учиться, чтобы ещё и с пользой — у него будет выбор из актуальных тем. Или если команде нужен человек с нужными навыками — они могут это показать, выставить requirements. Это вообще не про технические навыки вроде «опыт разработки на Phalcon/Flask/Express» — командам часто нужны мягкие навыки (soft-skills), которые составляют до 80% от навыков крутого специалиста. Ну там с заказчиками пообщаться, в команде зафиксировать решения, написать отчёт или составить тех задание. Так что это актуально для любой предметной области, для любой профессии. А в конце года оценить — насколько команда стала опытнее, насколько каждый в отдельности стал опытнее. В частности, достоин ли он повышения зарплаты.
Вернусь к теме топика: «Что делать, если деньги на проект получены и истрачены, а проект не готов», к моему фильму о собеседовании шесть лет назад.
С учётом всего вышесказанного, финал римейка:
Сейчас мы готовы показать и сдать в эксплуатацию то, что есть. И, скорее всего, оно уже даже эксплуатируется. Команда поддержки уже собирает отзывы, рекомендации, предложения, баг-репорты от конечных пользователей. Тестировщики тестируют. Дизайнеры и верстальщики улучшают интерфейс. Команда разработчиков уже доделывает проект. В проекте нет архитектурно-несовместимых 20%. В общем, мы работаем над этим проектом для устранения замечаний и будем выпускать в виде дополнения за наш счёт, пока не закроем требования исходного тех задания. У вас не будет никаких простоев. Мы отдельно собираем список новых требований, не согласующихся с тех заданием, новые фичи. Давайте перейдём к вопросам сопровождения и разработки этих и других новых фич, если вы выбираете нашу команду для продолжения работ по проекту… К сценарию сиквела нашего фильма.
Изображение Digital killed the Analog Star для обложки позаимствовано у Miguel-Santos
| 12% (44) |
я знаю достаточно, на текущей работе этого хватает |
| 1% (5) |
если будут заставлять учить что-то новое — найду место, где эти знания не требуется |
| 57% (217) |
на работе вызываюсь на задачи на неизвестных мне навыках, так и прокачиваюсь |
| 10% (38) |
у нас есть личный план развития сотрудника на год, чтобы оправдать следующий рост зарплаты |
| 33% (125) |
смотрю по требованиям вакансий / фриланс с бОльшей ставкой — на те технологии и учусь |
| 40% (153) |
выбираю тренды по темам на хабре или аналогичных ресурсах |
| 12% (45) |
выбираю наугад, что первое в глаза бросится |
| 21% (81) |
довожу до совершенства несколько своих навыков, неизвестные мне навыки осваиваю редко |
Проголосовало 380 человек. Воздержалось 149 человек.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (71)
maxru
20.03.2017 11:42+11К примеру, я за год изучил AngularJS 1, VUE,js 2, Twitter Bootstrap 3, Semantic UI 2, M.E.A.N., Phalcon 3, Yii 2, Laravel 5, Grunt, SCSS. Прокачался так, что голова кружится от ощущения собственной крутоты.
Хорошая иллюстрация эффекта Даннинга-Крюгера.
copist
20.03.2017 12:04Голова покружилась и прошла. Навыки остались. Ещё пригодятся.
Есть у меня ещё один навык, который получился в прошлом году. Я бы описал его так: насколько бы хорошо я не знал тему вопроса, нужно свой ответ отложить на самый последний момент, когда все высказались. Дай сказать всем, вытягивай из них мнения и решения. Ох, это сложно, особенно когда у меня решение крутится на языке и готово соскочить в любой момент. Но ради общего повышения навыка принятия решений нужно заткнуться и дать людям совершать ошибки, чтобы они учились. Я сам ошибался, на этом и учился. Нельзя других лишать возможности стать лучше.
copist
20.03.2017 12:14-1Вообще получалось так, что мои решения, болтающиеся на кончике языка, не были уникальными идеальными решениями. Команда выбирает такие же (то есть моё — не уникальное) и даже более удобные (то есть моё — не идеальное). Поэтому и утверждение, кто никто не умнее других в команде. А помолчать надо, чтобы они не стеснялись аргументированно выбирать решения.
Lelushak
20.03.2017 22:45>Команда выбирает такие же (то есть моё — не уникальное) и даже более удобные (то есть моё — не идеальное). Поэтому и утверждение, кто никто не умнее других в команде.
Правильно будет сказать, что вы не умнее остальных в команде. Обобщать это утверждение на всех остальных — неправильно.
intsurfer
20.03.2017 11:47-1>>Прокачался так, что голова кружится от ощущения собственной крутоты. Но в решениях компании, где я работаю, эти технологии не используются.
Несколько месяцев назад начал понемногу изучать python и совсем недавно nodejs. Чисто в самообразовательных целях, чтобы мозг не усыхал. И вот прямо на днях пришлось поднимать все знания, чтобы выбрать правильные решения для одного серьезного проекта. Неделя гугления и творчества и некий девайс подключен к компу с убунтой и они обмениваются данными. :) Теперь надо углубляться в Gtk3, чтобы дизайн был не в стиле HelloWorld.
ЗЫ Сам себя не похвалишь, никто не похвалит :)
habradante
20.03.2017 11:57+15Мой опыт подсказывает мне, что остаток в 20% сформировался не в последний день сдачи проекта. Такие риски реализуются ДО финала, а величина этого риска и характер (архитектурный) говорят о том, что он реализовался, если не сразу, то в конце первой половины — начале второй половины (срока) проекта. Так что ПМ и тимлид просто не смогли (или не захотели) увидеть этот риск. И указанные в начале статьи три финала — все результат более ранней ошибки.
Нельзя архитектора одного винить за плохую архитектуру. Как правило, архитектура после ее описания еще какое-то время от начала полируется и правится. И, если, с ней неудобно работать, она не выполняет своих целей, то кто-то в команде просто забил и сказал «ааа, не беда, накостылю», вместо того чтобы пойти к архитектору и сказать что он ошибся или спросить как решать такие-то и такие-то задачи.copist
20.03.2017 12:05Это же задача с собеседования. Там вопрос наигранный, гипотетический. Проверяет как кандидат мыслит терминами компании, команды и проекта.
> указанные в начале статьи три финала — все результат более ранней ошибки
Согласенhabradante
20.03.2017 12:27+8Понятно что вопрос гипотетический, но, на мой взгляд, он выглядит как «мы профакапили и надо найти кого наказать». Т.е. он не направлен на поиск причин, а только на то «как выйти из ситуации с наименьшими потерями».
В целом, я согласен, для фирмы третий вариант предпочтительнее, на короткой дистанции. Т.е. прямо сейчас сохраняется команда (вопрос только, а стоит ли), сохраняется репутация (только какая, что фирма не увидела приближающийся факап?) и фирма не выходит в минус.
Только вот, с точки зрения клиента, я бы с такой фирмой дел иметь не стал и этот проект был бы с ней последний.
Опять-таки, у клиента могут быть свои планы на дату финала проекта, у него может быть запланирована грандиозная распродажа или другая акция, закуплены товары, арендованы площадки. В общем, он УЖЕ потратился. И фирма ему врала все это время, что все закончится вовремя и все будет хорошо.
Я, как-то, погрузился в историю одной ИТ системы для аэропорта. Суть в том, что разработчик обещал сдать систему вовремя, и заказчик уже распланировал мероприятия, расписал бюджеты и начал даже их тратить. И в последний момент оказалось что система не готова. Суммы за простой аэропорта там были астрономические. А сроки до сдачи в эксплуатацию системы составляли еще несколько месяцев после формальной сдачи проекта.
В общем, если бы дело было в Китае или в Японии, то, думаю, все закончилось бы человеческими «жертвоприношениями». Чем закончилась история с аэропортом для разработчика, история умалчивает.
Все эти примеры, конечно, не касаются гипотетического вопроса на собеседовании, но в таких случаях всегда надо понимать, что сдача проекта это событие не только для разработчика, но и для заказчика, и последний, может нести дополнительные убытки от таких «замалчиваний».copist
20.03.2017 12:47Как пишут, первый iPhone показывали не 100% работающим :)
> «как выйти из ситуации с наименьшими потерями»
Первые три вариант финала — да, поиск такого варианта.
Такое со мной случилось бы только в случае, если мне уже сунули в руки дохнущий проект. Пришлось бы извиваться и запускать сырой, прикрыв дыры, чтобы не срывать сроки, искать свободные руки и финансы для завершения, а то и дописывать наравне с другими. В случае провала мне пришлось бы уйти, дабы не чинить расправы над выдохшейся командой.
В разработке ПО финал с человеческими жертвоприношениями — это если фейл обнаружится в системе управления космическим кораблём, логике самоуправляемого автомобиля,Скайнете,автоматической системе жизнеобеспечения в медицине. Причём умер бы конечный пользователь. А разработчик максимум отсидел бы срок, но всяко не смертная казнь.Скайнет не всчёт.Китай не в счёт.
В определённом смысле это всё риск. Надо быть готовым ко всему. Мы можем зафакапить презентацию, но и заказчик может разориться ещё до наступления года. Контрольные точки, спринты, ретроспективы — они для того, чтобы не получить фейл через год, а приблизить во времени цепочку обратной связи от заказчика и конечных пользователей. Получить фейл через 3 месяца, например.
Последний абзац, финал римейка:
И, скорее всего, оно уже даже эксплуатируется. Команда поддержки уже собирает отзывы, рекомендации, предложения, баг-репорты от конечных пользователей. Тестировщики тестируют. Дизайнеры и верстальщики улучшают интерфейс. Команда разработчиков уже доделывает проект.
Это и есть тот вариант, что мы уже давно его запустили, теперь собираем баги и дописываем код по ТЗ. Всё пучком.
rfvnhy
22.03.2017 16:03В случае аэропорта (или аналогичной ситуации, когда срыв сроков ведет к крупным потерям) или они нанимают фирмы (и заключают правильные договора), которые «если что» смогут «ответить» возместив потери и почти не контролируют их работу (обычно это очень крупные фирмы, которые сами себя проконтролируют, что бы не потерять средства) или очень строго контролируют сроки поэтапно, в случае затягивания очень быстро меняют исполнителя…
Либо все сроки надо умножить как минимум на два, но не говорить об этом исполнителям — успеют раньше — отлично, не успеют — пусть заканчивают, но платят неустойки «что бы не было повадно» остальным и на будущее…
sspat
20.03.2017 11:59+4Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново.
В такой ситуации мне кажется виноваты все. Архитектор в том, что очевидно скрывал до самого последнего, что 20% нельзя будет реализовать на текущей архитектуре — первые признаки должны были появиться намного раньше, чем практически под сдачу проекта. Техлид виноват в том, что не увидел эту проблему сам и узнает о ней под сдачу проекта от архитектора — у техлида не хватает технической компетенции для самостоятельного анализа. Разработчики — в том, что сделали настолько связанную систему, что при добавлении 20% нового функционала ее приходится переписывать полностью. Отстранять в первую очередь тут надо тех-лида.
Draconian
20.03.2017 12:24+3Мне любопытно, что бы автор сделал, если бы заказчик попался не глупый, и на пред-дедлайновом совещании задал вам совершенно конкретный вопрос, ожидая конкретного ответа — готова ли на данный момент фича N (из нереализованных 20%)?
На мой взгляд, если вы нарушили договор, вам так или иначе придется доделывать эти 20% бесплатно, и выкачать дополнительные деньги за реализацию дополнительных фич вряд ли получится (по-крайней мере, до 100% сдачи проекта).copist
20.03.2017 12:28флексить :) дурацкий термин, означающий что можно попробовать сдать в эксплуатацию путём урезания чего-нибудь, не в ущерб продукту в целом.
Сейчас я отвечу на такой вопрос только если мне дадут конкретный пример и возможность пообщаться с командой. Без этого я все свои пришедшие на ум советы помечу ярлычком «draft», рабочий вариант.
Бесплатно доделать — это вариант, озвученный в финале. Потому что у моей команды есть резерв. Но там не было бы 20% архитектурно-несовместимых решений.Draconian
20.03.2017 12:43Я имел ввиду, что вы бы сказали заказчику на месте? Что вам необходимо уточнить этот момент у команды?
Вообще, постановка задачи странная — 80% реализовать можно, а 20% — никак нельзя в текущей архитектуре?
При планировании такие риски должны были быть четко видны, теоретически. Получается, проект уже был «провален» на начальной стадии.copist
20.03.2017 12:54+1Если бы я знал что через год 20% не могут быть сделаны, я ещё до встречи с заказчиком все детали у команды выяснил. И пути решений составили бы. В целом конечно это означает «спросил у команды», но не так явно, чтобы не работать прослойкой между командой и заказчиком.
Только в моей истории я бы не дошёл до «20% не могут быть сделаны, ой» через год. Потому есть техники, которые позволяют выявить проблемы до финальной стадии сдачи. Промежуточные релизы, тестирование на контрольной группе, альфа-версии, бета-версии.
Потому что есть понятие MVP, согласно которому система реализуется частями, при котором за каждый контрольный срок реализации система дописывается сразу по всем аспектам, а не вылизывается один единственный аспект.
Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.Draconian
20.03.2017 13:08+1Как я и сказал, постановка задачи довольно странная: при использовании любого более-менее современного подхода к проектированию \ реализации такие проблемы должны быстро выявляться.
Спасибо за ответы.
rfvnhy
22.03.2017 16:19>Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.
Это всё отлично, но к сожалению, не всегда применимо.
Как пример можно привести постройку здания.
Фундамент необходимо закладывать первым.
А постройку крыши и финишную отделку придётся откладывать на самый конец строительства…
Другой вопрос что в таких проектах всё же обычно участвуют конторы с большим опытом и они могут заранее предсказать большую часть проблем и варианты решения.
copist
20.03.2017 13:12Примеры проектов
1. Большая система чего-либо, где 20% — это искусственный интеллект. Его писали писали и ничего не получилось. Но разработчики показывали идеальную модель, отлично работающую на тестовых данных. В итоге вся система не работает.
2. Система, подразумевающая интеграцию. Но 20% этой системы находится не под контролем команды и они не готовы, хотя они отписывались об итогах и тесты проходят. В итоге вся система не работает.
3. Игра, в которой нужно определённое железо, но это за пределами программного кода проекта. Ну типа нестабильность игровой приставки. Разработчики игровой приставки обещали за год выпустить SDK с исправлениями и заменить чипы в новых версиях железа, но выпуск отложен. Вся игра работает только на пропатченных консолях у разработчиков, но они не могут патчить консоли конечных пользователей. Вся система не работает.
4. Система, в которой функционирование реализуется только путём участия третьих лиц, и привлечение этих лиц взял на себя кто-то другой, но так никого и не привели. Незнакомая ситуация? Ну представьте, что на Booking.com так и не пришли владельцы отелей. Посетители есть, отелей нет. Вся система не работает.
Это я так, наугад придумал.
Archon
20.03.2017 14:16Опять же, ни один из четырёх примеров не является внезапным факапом, сваливающимся на голову в последний день.
1. Это предсказуемые риски, которые необходимо было сразу огласить заказчику и иметь пути отступления. В идеале подобные вещи надо оформлять в рамках отдельного проекта, уже после пусконаладки основного продукта, а не делать «проект в проекте» с малыми шансами на успех.
2. Если интеграция является требованием заказчика, то это вполне можно (и нужно) объяснить заказчику. Не исключено, что он после этого сможет ускорить процесс, придав импульс нужным действующим лицам, и процесс завершится успешно. Если же вы добровольно завязали ключевую архитектуру на работавшую (на тот момент) интеграцию со сторонним сервисом, а сервис бесславно обанкротился, сломался, или поменял концепцию до окончания года — это просчитываемая ошибка.
3. Золотое правило: при разработке любой вещи ориентироваться только на то, что есть здесь и сейчас. Если на текущей версии библиотеки (приставки, чипа, операционной системы, и т.п.) код не работает, но разработчики клятвенно обещают к концу года это исправить — их слова пропускаем мимо ушей, а принимаем только то, что код не работает и надо искать обходные пути.
4. «Пользователи не пришли» — это симптом, а не болезнь. Надо разбираться, почему не пришли, что им помешало. В итоге, когда вы докопаетесь до истины, будет установлена конкретная причина, и её вы и будете конкретно решать.rfvnhy
22.03.2017 16:503. код не работает, но разработчики клятвенно обещают к концу года это исправить — их слова пропускаем мимо ушей,
Ну тут вопрос в чьей стороне ответственности эти разработчики.
Если со стороны заказчика — проблему надо решать или заказчику или совместно, или вам, но заказчик платит за всё.
Если со стороны исполнителя — проблема или целиком ваша или решить с заказчиком совместно, но с оплатой — зависит от частностей. Например был ли заказчик в курсе возможной ситуации (и об этом есть в ТЗ/договоре) или нет.
и тд и тп
Germanets
20.03.2017 14:16Во всех 4х ситуациях — есть конкретный виновник, в самой команде(плохой вариант) или вне её:
1. Ответственность на тех людях, которые принимали решение, когда взяли на себя задачу по реализации данных требований(а не задачу на исследование), а также те, кто принимал решение о тестировании на неподходящих данных.
2. Ответственна та компания, которая должна реализовать необходимые 20%, соответственно — все издержки и претензии — на неё.
3. Каким-то образом был закреплён тот момент, что игра требует более новые версии железа? если да — все вопросы формально на стороне заказчика — что заказали, то и получили.
4. «привлечение этих лиц взял на себя кто-то другой» — вот этот самый другой и есть ответственный за ситуацию.
И да — во всех случаях, кроме разве что первого — проблема при должном мониторинге известна куда раньше, чем самый последний момент.
vintage
21.03.2017 06:53+1Ну нашли вы на кого свалить всю вину. Дальше-то что?
rfvnhy
22.03.2017 16:52А дальше решать проблему.
Вопрос кто за это решение будет платить и понесёт убытки — зависит от конкретики и договоров.
Это либо целиком заказчик, либо целиком исполнитель, либо какое-то совместное решение…vintage
25.03.2017 13:29Ну, если единственная ваша проблема в том, кто за всё будет платить, то, конечно, нахождение виноватого — это уже пол дела.
Но на мой взгляд важнее следующие проблемы:
- как всё-таки решить задачу клиента, за которую он уже заплатил.
- как не потерять клиента или хотя бы репутацию и как следствие возможность дальнейшего развития.
- как не потерять команду и как следствие бизнес.
Но ок, допустим вы выяснили, кто виноват. Как правило тот, кто виноват, не примет ваших обвинений. выставляя себя жертвой обстоятельств или перекладывая вину на других. Это приведёт к конфликту. Например, вы обвинили:
- Архитектора. Он обижается и уходит. Остаётся некому выстроить правильную архитектуру.
- Разработчиков. Они обижаются и разбегаются. Некому латать дыры в тонущем корабле.
- Клиента. Он обижается и даже если и соглашается на ваши условия, то к вам больше не возвращается. А то и пустит слух, что вы не компетентны.
Заметьте, всё это независимо от обоснованности ваших обвинений.
Важно понимать, что любой конфликт в условиях ограниченных ресурсов очень быстро эскалируется до неприличных масштабов.
Lofer
25.03.2017 22:04как всё-таки решить задачу клиента, за которую он уже заплатил.
Ключевой вопрос обычно так и звучит: а заплатил ли клиент за решение задачи?
Т.е.: корректно ли у клиента сформирована тестовая среда, по графику клиент предоставлял информацию, корректно ли были выбраны и сформулированы критерии приемки? Согласовывался ли бюджет после внесения изменений?
Клиента. Он обижается и даже если и соглашается на ваши условия, то к вам больше не возвращается. А то и пустит слух, что вы не компетентны.
Юридические основания? Аудит проекта и счет за судебные издержки за клевету и разрушение деловой репутации такому «клиенту». Сам получил «звание» Неадеквата/Сложного Клиента и т.д.
rfvnhy
22.03.2017 16:47+1>2. Система, подразумевающая интеграцию. Но 20% этой системы находится не под контролем команды
Вариантов множество....Если интеграция со стороны заказчика — то это не ваши проблемы.
Их решение вы можете взять на себя за отдельные деньги (и сроки)
Если интеграция с вашей стороны и заказчик не в курсе (в договоре не прописано) что вы будете что-то «брать со стороны», то это в 1ю очередь ваши проблемы.
Иногда их можно списать на форс-мажор, иногда нет.
Обычно в такой ситуации надо решать с заказчиком что и как можно сделать.
Например «таможня задержала поставку оборудования» — идет срыв сроков,
в крупных конторах обычно есть свой «подменный фонд» или даже склад, который можно временно задействовать, если у заказчика «горят сроки», если же вариантов нет — надо решать с заказчиком — или ждать или менять оборудование на совместимое или даже править код что бы заработал на аналоге — но это всё надо заранее решить с заказчиком.
Иногда заказчик может понять ваши проблемы и предложить даже своё решение или помочь решить затруднения… Иногда вы попадете на судебный иск об издержках или даже убытках.
Все зависит от очень конкретной ситуации и документов к ней.
Абстрактных примеров множество, а вариантов решения еще больше.
Если например должны поставить на Луну/Марс запас кислорода для купола, под которым живут люди — там будет речь идти об очень жестких сроках и некотором их запасе (если это не аварийная доставка, то запас должен быть, вопрос какой), а вот в случае провала всех сроков — скорее всего виновник станет причиной гибели людей. Грамотное руководство например должно рассчитывать минимум 2-3 кратный запас таких вещей, но ведь бывают и аварии с утечкой.
Что будет делать руководитель из примера в статье в этом случае?
В общем без конкретики задания такой вопрос (из статьи) можно решить только «для общего случая», а лучше всего начать задавать интервьюеру наводящие вопросы о сути задания — иногда именно этого они и ждут.
Т.е. если вы кинулись отвечать на задачу с неполными данными и дали не верный ответ — вы не пригодны. Если начали задавать нужные вопросы, но ответ был дан не совсем верно — могут взять помощником, а потом посмотреть/обучить/… и тд и тпcopist
22.03.2017 20:15Т.е. если вы кинулись отвечать на задачу с неполными данными и дали не верный ответ — вы не пригодны. Если начали задавать нужные вопросы, но ответ был дан не совсем верно — могут взять помощником, а потом посмотреть/обучить/… и тд и тп
Да, сейчас я придерживаюсь такой же точки зрения. Надо было устроить диалог.
rfvnhy
22.03.2017 16:16Вот кстати чего не хватает многим зафейленым краудфандинговым проектам (если там не было злого умысла изначально) — вовремя понять что «что-то не так» и попытаться выйти из ямы наиболее оптимальным и менее затратным для конечных пользователей способом.
А уж скрывать от конечного заказчика явный фейл со сроками или качеством получаемого результата — подписывать «смертный приговор» своей репутации, а иногда и фирме — могут неустойками или возмещением ущерба разорить до банкротства…
Иногда лучше заранее предупредить заказчика что не успеваете/не можете обеспечить требуемое. А дальше решать что можно сделать с этим совместно — или вам дадут доп. сроки (если ему не горит) или вам выделят доп. средства (для найма добавочных специалистов, но когда сроки горят) или вы отдадите всё, что успели сделать заказчику получив хоть какую-то оплату (за вычетом неустоек).
Это всяко лучше, чем до последнего дня говорить что всё будет сделано в срок, а потом «пропасть» со связи или сдать неготовое/непригодное к использованию…
Иногда от результата вашего труда могут зависеть другие проекты (как в примере с аэропортом) и если у заказчика будет время сманеврировать (добавить финансов/нанять другую фирму/...) скорее всего репрессии по отношению к вашей фирме будут значительно меньшие (в идеальном случае вообще отсутствовать), чем в случае полного фейла в последний день…
nApoBo3
20.03.2017 12:29+8ИМХО выявление подобной проблемы на этапе «опытной эксплуатации» говорит о фундаментальных проблемах в компании.
Скорее всего было немного не так, вероятно проблема в том, что ни виноват никто. Т.е. никто так и не взял на себя ответственность за проект, и это скорее роль ПМ.
А было, думается, так. Продажник облизывал клиента и говорил все можем и даром, и быстро. По дороге от продаж к архитектуре некоторые требования, то забывались, то вплывали. Проблемы были отложены на потом. Отдел продаж давил на архитектора в сроках и намеренно сглаживал острые углы фразами ну это мы обсудим позже или выкинем( примерно как в истории про красные линии ). Архитектор прогнулся. Потом была гонка со временем и выплывание забытых фич, все обрастало костылями, ближе к концу проекта архитектор по ночам крутил и вертел эту конструкцию заляпывая, что отложили на потом. В определенный момент конструкция теряла прочность и начинала сыпаться. Техлид получал требования в разнобой параллельно с поддержкой и багофиксом, как результат в них утонул и утерял общую конструкцию из виду, а может и видел ее совсем по другому. При этом задачи сваливался ну вот прямо сейчас надо фиксить, как результат проект плыл туда где проще и костыльнее код, а не туда куда правил архитектор.
Вышло, что вышло.
Заказчика прогибать на функционал, остальное подпереть костылями, больше никогда так не делать, но боюсь будет именно так.
ИМХО провал концепции ввяжемся разберемся, плюс недостаточная компетенция участников( а может и не достаточная воля ), часто такое можно видит когда разработка идет от продаж и им же курируется. Вот здесь нужна прокладка из очень жесткого и квалифицированного ПМ'а, который не позволить забыть, отложить на потом или продавить. И я полагаю все участники проекта видели куда плывем, но никто не взял на себя ответственность это озвучить. Продажники рассчитывали, авось разгребем и кормили клиента обещаниями, архитектор, «я боюсь об этом думать», тимлид, это не мое дело, будут требования будет код, а у нас аджайл и дальше двух недель мы не смотрим, директор, ну я тут по делам отойду вы уж решите этот вопрос между собой, но если, что обязательно меня в копию, хотя я и не читаю.copist
20.03.2017 12:59+1Хм. Ситуация понятная. В подобном довелось участвовать только со стороны разработчика, но описано очень жизненно, как при этом ПМ юлил и выёживался у заказчика. Ну и как мы относимся к коду :)
rfvnhy
22.03.2017 17:01> Продажник облизывал клиента и говорил все можем и даром, и быстро. По дороге от продаж к архитектуре некоторые требования, то забывались, то вплывали. Проблемы были отложены на потом.
Была не очень давно история где-то в байках на эту тему…
Про то, что менеджер пообещал «за три ночи и три дня» когда реальный срок был существенно выше или требовал большего кол-ва разработчиков, принял на исполнение, а потом сначала предлагал, а потом навязывал разрабу эти сроки с этим проектом, а потом на совещании менеджер огрёб по полной — проект был доделан за счёт этого менеджера — начальник прочитал логи переписки разраба и менеджера и встал на сторону разраба…
К сожалению сходу не могу найти, но может кто-то вспомнит.
darii
20.03.2017 12:42+1Не знаю, как бы поступил с мелким проектом, возможно они прощают ошибки, но функциональный разрыв (functional gap) в 20% на проекте в десятки человеко-лет не лечится никак: в лучшем случае банкротство, в худшем — уголовное дело. Если директор проекта узнает об этом за месяц до подписания актов, то он — либо введенное в заблуждение подставное лицо, либо его задачей является осознанное сокрытие хищения денежных средств.
Интересующиеся новостями петербуржцы могут наблюдать последние несколько недель очень похожую картину в городских новостях: шла приёмка СИЗО «Новые Кресты», подписали акты, выявили оцененные в приблизительно 10% от суммы заказа functional gap, произошло заказное убийство и все заверте…copist
20.03.2017 12:56-4Ой, батюшки! Вот оно — как в Китае — смерть за факап проекта. Страшно, честно. Не хотел бы участвовать в таком.
SpyDeX
20.03.2017 13:13+4Какая-то очень странная и ситуация и выводы, слишком много вопросов возникает:
1) Я не настаиваю, но весьма криво выглядит ситуация, когда деньги распределяются из единственного внешнего заказа, без страховки (не оставить на чёрный день, не имея дополнительных паралельных источников).
Это странно!
2) Прожект менеджера, я так понимаю или просто нет, или уборщица по совместительству.
Кому сгружались данные на этапах каждого месяца квартала? Кто видел, что его квартал за кварталом кормят завтраками и ничего не предпринимал? Кто поверил словам разработчиков настолько, что перестал держать руку на пульсе и не считал, как с каждым днём, шансы сделать в срок скатывались в отрицательную зону?
3) Если должностное лицо, общающееся с заказчиком видело хотя бы за квартал, полгода, что проект медленно натягивается на глобус и никак не стал передоговариваться с заказчиком, то этот человек должен занять очередь на натягивание себя на глобус.
Можно хаить архитекторов, можно хаить техлидов, если они врали насчёт реального положения дел, то их стоит дауншифтить, если они говорили как есть, то тот кому они говорили всё как есть, прос… ал сам проект, пока видится проблема в руководстве, прокутившее где-то по кабакам, не следя за исполнением заказа.
Во всяком случае, неожиданностью 20% недоделок в последний день быть просто не может, об этом все знают заранее.copist
20.03.2017 13:15-2Гипотетические проекты с факапом в финальной стадии #comment_10126724
SpyDeX
20.03.2017 14:01+1Сильно гипотетики, да.
2,3,4 в которой опять ни техлид, ни архитектор не при чём.
ПМ и вся бригада профукала этапы общения со внешними звеньями,
4) договариваться год о встрече? если встреча такого масштаба, то она важна всем сторонам.
Если там единственный приглашённый владелец, и он просто не приезжает, то ему это не нужно было с самого начала. Если масштаб потерь серьёзный, то риски оговариваются обеими сторонами, можно либо договорится для подстарховки «спикерами от владельца такого-то». В крайнем случае обговорить/огранизовать онлайн встречу (видеофонию), не в последние же 5 минут оказывается, что человек не доступен на планете!
3) Взять у заказчика контракт на подготовку к несуществующему железу, и не обговорить, что если железо не выйдет на рынок, то и игра не взлетит? ну-ну.
2) то же, что и предыдущий пункт. Только тут риски как минимум пополам делятся, за год не получить средств интеграции, это опять должен быть либо совсем мегаогромный проект, и год — не срок, либо очень хилый менеджмент, оставивший на самотёк самый рисковый этап на конец срока исполнения.
1) об ИИ тоже не надо думать как о магии, математика она и есть математика, она как минимум будет работать, на 20% будет недорабатывать математика? есть над чем склонить голову.
В общем примеры и правда надуманные, к исходной ситуации, описанной в статье они вряд-ли имеют хоть какое-то отношение.
Любые риски внешних факторов при обсуждении заказа фиксируются, и по ним обычно формируется группа, отслеживающая эти риски, тянуть до срока сдачи нет никакого желания ни у кого, потому что абсолютно все держат на кону деньги.
Либо просто организованное кидалово, но это уже грязь, которую обсуждать нет желания.rfvnhy
22.03.2017 17:08Ну из относительно близких к реальности примеров к интеграции —
в проекте всё завязано на микросхему, выпускаемую в Китае крупным заводом.
К моменту сдачи заказа оказывается что завод месяц как перестал её выпускать, на складе осталось 100шт (а надо как минимум 1000), ради 900 шт завод перезапускать линию не будет, переделывать под другую м/с слишком дорого/сложно/…
Но и тут есть фейл со стороны разраба.
Если были уверены что проект будет именно на этой м/с, то должны были или закупить сами заранее или договориться о такой закупке с заказчиком заранее (если это его часть ответственности), а уже потом приступать к основной части проектирования.
Причем закупить лучше с хорошим запасом(если позволяет цена с многократным).
SpyDeX
21.03.2017 11:59А так, отвечая именно на вопрос собеседования, наверно стоит собрать команду заново,
оценить какие учтённые и неучтённые риски привели к таким результатам,
просчитать объём работ по устранению недоделок,
пересчитать риски по каждому спектру работ,
назначить на каждый риск ответственного (не важно сколько их, даже если 1 человек будет ответственный, но со стальными шарами),
пересчитать необходимые сроки для разрешения недоделок,
послать результаты расчётов переговорщику с заказчиком, всё по результатом совещаний высказать, после провала лучше побыть честным,
Если заказчик согласится на доделки, то приступать к работе,
каждую неделю ( а в дисциплинарных мерах «за заслуги» можно и раз в день ), спрашивать прогресс по каждому спектру работ.
И искать следующие проекты, перераспределить команду так, чтобы можно было вести больше 1-го проекта одновременно, Если плавно распределять не получается, просто разделить людей пополам, на команду А и Б, всё равно коммуникация между командами и взаимопомощь останется.
Если хочется оставить компанию на плаву, можно и перекредитоваться, технари всё не владельцы бизнеса, денежные вопросы не должны отвлекать от работы.
Durimar123
20.03.2017 13:43Не забываем что «на последние 10% объёма задачи нужно будет потратить 90% времени».
TimsTims
20.03.2017 15:45+1Финал 5й: допустим, что проект готов на все 100%, и деньги все потрачены. — Увольняем всех, т.к. других заказов в запасе всё-равно нет(по условиям кейса), а значит любая концовка смертельна.
Выводы: нужно всегда иметь в запасе несколько проектов, которые могут перекрыть.
RomanYakimchuk
20.03.2017 15:55Насколько я понимаю, почти любой сценарий выльется в вопросы заказчика, и итоге в обозначенную некомпетентность всех уровней в компании, каждая из которых должна была заложить свои риски. Если случилась такая ситуация, значит профакапились все уровни, от разработки до проектного отдела. По репутации компании будет сильный удар.
Если текущего состояния проекта достаточно для введения в коммерческую эксплуатацию, можно отдать продукт в коммерцию, и постепенно закрывать хвосты за счет компании, т.е. за свой счет. Так репутация пострадает не сильно, команда не уйдет, и в итоге проект будет сдан.
Можно выбить время путем обсуждения ТЗ (всегда есть что можно улучшить, ошибки в ТЗ, и прочее), пакетов доработок которые можно внедрить сейчас, импрувы продукта которые непременно нужны на старте в коммерции, и далее цикл согласования. Если проект действительно крупный, это может дать нужное время команде на закрытие хвостов. Работа команды оплачивается за свой счет. Так репутация не пострадает (возможно, даже выростет, мол побеспокоились о продукте, помогли, сделали лучше чем нужно), команда не уйдет, и продукт будет сдан в срок (новый, согласованный).
Если уже совсем край, дедлайн прямо завтра, тогда ничего не остается, кроме как посыпать голову пеплом, проанализировать текущее состояние, сделать переоценку, заложить риски, согласовать. Это будет менее болезненно. Дальнейшая доработка за свой счет.
Отвечал чисто на вопрос из заголовка статьи, из интереса верное ли мышление (не являюсь руководителем отдела разработки). Комментарии и статью предварительно не читал.
Такие решения приемлемы?
Lofer
20.03.2017 15:56+2Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново.
Бред какой-то…
- Как клиент умудрился оплатить 80% функционала 100% денег ?
- Как умудрились подписать котракт не имея критериев приемки ?
- Как умудрились разрабатывать и дизайнить не имея критериев приемки?
- Как умудрились найти ПМ который не предусмотрел риски для таких бюджетов?
Это какие юристы ИТ компании пропустили такой бред на подпись ?!Lofer
20.03.2017 16:11Формально — проблема Подрядчика. Я бы на месте клиента еще и неустойку вытряс :)
Архитектор — не думаю что он виноват. Обычно роль архитектора такие косяки предовращать и видеть «вперед» «до финала», он же с упреждением работает.
Код не его проблема.
Вопрос откуда и в какой момент вылезли эти 20% и как их оценили? Если ПМ адекватный то можно и на Change Request / доп соглашение опираться…
Lofer
20.03.2017 16:24И если оплачено 100% по актам приемки с 80% функционала без указания перечня дефектов то… проект успешен. Нет проблемы :))))
impetus
20.03.2017 18:10+1Как клиент умудрился оплатить 80% функционала 100% денег ?
Вы возможно будете смеяться — но в самолётостроении такое происходит уже лет 20 — во всех странах: у нас, всех америках, европе, азии — в гражданском секторе… В военном и 200% у всех-всех на планете не выгядит чем-то чересчур. Да и полные провалы с отменой заказов на уже полетевшее — не такая уж редкость (чаще маскируют сверхмалой штучной серией 3-5 бортов, что бы не выглядело совсем уже попилом, при том что это не распил-откат, а честные технические провалы — не срослись характеристики реальные с многажды правленным ТЗ.)Lofer
20.03.2017 19:45+1Это я понимаю. Есть юридические механизмы, позволяющие передать всю сумму денег за частичный результат. Но на это делается соотсветсвующая юридическая бумажка, закрывающая будущие взаимные претензии обеих сторон.
И опять же, это не приводит к состоянию «уволить архитектора», при нормальном развтии событий.
rfvnhy
22.03.2017 17:20В таких проектах это всё обычно предусматривается в первую очередь в документах. Или повышенной ценой проекта (что бы в случае провала 1 из 10 компания не закрывалась) или повышенной ценой риска проекта «мы будем работать почти без прибыли, но результат не гарантируем» (такое часто в оборонке — предприятия на гос. обеспечении, получают за заказы только себестоимость + самую минимальную прибыль).
Опять же в приведенных вами ситуациях нет 100% провала — часть денег «вернется» найденными техническими решениями, которые будут использованы в других проектах.
Часть проектов можно доделать за разумные средства в разумные сроки.
Или дождаться выхода новых технологий/материалов/аппаратуры/… и доделать проект…
Или где-то можно изменить ТТХ до приемлимого обоими сторонами.
100% провальный проект только или в случае злого умысла или от полной некомпетентности или всей команды или отдельных ее членов.
Например согласиться строить танк весом в 1000 тонн, который должен будет ездить по обычной почве в отсутствии работающей технологии антигравитации скорее всего будет или явным попилом/диверсией или разрабами, которые ничего не понимают в своей области…
fastwit
20.03.2017 17:29+3Задача, очевидно, менеджерская, а не техническая поэтому ответ может быть таким:
1. Сразу уведомить клиента. Пока все будут жевать свои сопли, клиент начнет терять деньги или даже бизнес.
2. Определить альтернативные варианты по основным осям ресурсов: деньги, сроки, компетенции, люди. Например, допустим у нас много денег, тогда есть такой вариант. Или у нас есть возможность еще год тянуть эту лямку — тогда вариант второй. И так далее… Выбрать один из вариантов или синтезировать из них компромиссный.
3. Определить объем и план работы по выбранному варианту и предоставить клиенту. Если вы просто скажите клиенту «мы все решим» — вам не поверят. А вот если вы покажете шаги которые вы собираетесь предпринять, то у клиента будет, во-первых, уверенность в том, что проблема решаема, во-вторых, он будет видеть график выхода из кризисной ситуации и сможет скорректировать свои действия, чтобы бизнес внезапно не перестал существовать.
4. Уведомлять клиента о достигнутых вехах.
5. Сдать проект и подписать клиента на тех. поддержку.
6. Найти виноватых и принять меры. Задокументировать кейс, чтобы исключить подобные риски в будущем.fastwit
20.03.2017 17:57+2Случай из жизни. Большой азиатский провайдер услуг заказал большую систему. За месяц до окончания проекта команда разработки сталкивается с форс-мажором и заявляет, что к сроку не успевают. Речь шла тоже об около 10-15% функционала.
Речь шла об интеграции со сторонней системой. Виноват оказался менеджер проекта, так как интеграция была запланирована календарно и до определенного момента к ней не приступали. А в ответственный момент пошли многочисленные накладки на той стороне, то главный разработчик в отпуске, то их менеджер заболел. Менеджер проекта поседел в тот же день. Неустойка составляла $5000 за каждый день просрочки запуска.
Со словами «репутация дороже денег» он пошел «сдаваться» к клиенту. Клиент не был доволен конечно, но они нашли способ отложить запуск без серьезных потерь для бизнеса. Но так как срок в контракте нельзя было подвинуть сделали дополнение к контракту (change request), в которое включили несколько мелких фич, не влезших в изначальный объем. Понятно, что за доп. фичи еще к бюджету добавили.
В итоге все кончилось хорошо. Команда все равно немного просрочила запуск, на два дня, вроде бы. С них взяли неустойку. Но она была в пределах заложенных премий для менеджмента.
red_fish
20.03.2017 18:37после прочтения сложилось ощущение, что не все на своих местах работают.
copist
20.03.2017 18:39Ну, я точно на месте лидера тогда был бы не на своём месте. Даже сейчас не уверен.
red_fish
20.03.2017 23:07+1Сомнения в себе не лучшие качества лидера) А по данной тебе, думаю, что это был вопрос помогающий определить ваш градус ответственности и уверенности в своей компетенции. Отвечать следовало примерно так:
1. Говорим, что с вами этого бы не случилось, т.к. задача тех.лида ещё на старте предусмотреть возможные грабли и подобрать правильную методологию разработки. Гнать на архитектора не вариант, вы отвечаете за команду, весь спрос с вас. Если обстоятельства не от вас зависят, то спрос с вас никуда не деется, а линь нивелируется вашей способностью решать подобные ситуации.
2. Раз уж проблема выявлена и пошла пьянка, то просим уточнения для описания проекта. Есть Показываем, что разбираемся в системах (complex/complicated). В одном из случаев возможна частичная отгрузка с продолжением разработки. На израсходованный бюджет отвечаем, что этот риск был заложен в стоимость разработки. Однако прежде чем использовать выручку своей фирмы для доделки, говорим, что готовы обсудить с заказчиком возникшую проблему и найти совместное решение. Серьезные заказчики, всегда подстраховываются и предусматривают, что разработка может не быть закончена в срок, неустойка никому не на руку — софт нужно будет обслуживать.
Итого вы должны были показать, что: уверены в себе, понимаете бизнес-процессы выше вас, готовы частично совмещать в себе обязанности менеджера проекта, умеете признавать ошибки и не боитесь браться за их решение, и главное — не перебрасываете ответственность на подчиненных, даже если это их косяк.
Если после не дают конкретный кейс, то на этом ответ можно считать оконченым.
DaMaNic
20.03.2017 18:38+2Сидел на реализации одного проекта (не в области ИТ, в области нефтепереработки). Задача была не аналогичная, но принцип похожий — у Заказчика свое видение функционала, к ТЗ припаркован талмуд «хотелок», которы продажники взяли и принайтовали к договору, у исполнителей-субподрядчиков свое видение, основанное только на ТЗ в обрезанной немного версии, у меня — субподрядчик с четким договором, шесть исполнителей под рукой на оставшуюся работу, мнение директора что «Заказчик должен быть доволен», и тоска в глазах… Решение было единственное — на что то согласиться (доработать необходимые работы напильником), где-то Заказчика притоптать, сославшись на нестыковки ТЗ и «хотелок», где-то притоптать субподрядчика, сославшись на достигнутые договоренности и принципы «честного бизнеса» — утопят нас мы утопим вас. В итоге Заказчик получил то что ему было нужно, директор не потерял денег и получил свою прибыль, подрядчики тоже сработали неплохо, из минусов — отрицательная репутация моя у директора, т.к. цейнот был у меня, а у директора были жалобы от Заказчика и субподрядчика на мою слишком сильную инициативу.
AlexLeonov
20.03.2017 23:09Печальная история о том, что в команде проекта нет человека, который лично, своей задницей, отвечает за превращение оценки в человеко-часах в сроки на календаре.
Пока такого человека не появится, пока он не взвалит на себя тяжкий труд разбираться в каждой конкретной ситуации в магии таких преобразований — фейлы будут вас преследовать на каждом проекте.
Программист дает оценку задач. И отвечает за свою оценку в разумных пределах.
Тим-лид? Дает сводную оценку трудозатрат и рисков. И отвечает за эту оценку.
Сроки? Это не сюда, это к тем, кто работает с заказчиком. Программист не должен ничего знать о сроках. Его задача — сделать задачу, оцененную в 2 часа, не более, чем за 3 часа. Грубо говоря ))
t0ly2013
21.03.2017 05:43+1кажется немного сумбурно получилось, но идея отталкиваться от команды в целом и уважать более опытных — кажется вполне разумной.
KolyaniuS
21.03.2017 14:48Не понял, а куда прибыль потрачена? 100% оплачено — это ведь не только зарплата разработчиков и уборщицы вместе с тим-лидом. Или руководитель проекта уже уехал на море и потратил весь бюджет на профурсеток, не закончив работу…
rfvnhy
22.03.2017 17:26Ну как в некоторых краудфандинговых проектах (тут эта история была точно, кажется про микро-квадрокоптеры) — разрабы купили себе по бентли и отдохнули в стрип-барах на всю катушку…
copist
21.03.2017 15:15Интересная ситуация в комментариях наблюдается
Часть обратила внимание на потраченные 100% при невыполненной работе, типа вот ведь разгильдяи, вруны, распильщики, некомпетентность на всех уровнях. Даже смертную казнь упомянули и кровавые расправы.
Часть обратила внимание что через год обнаружилась фатальная несовместимость решения.
Неправдоподобно. Там с первых строк прям ультра-косяк продакт-менеджера — тянул до последнего. Даже при ватерфлоу так запускать не получалось никогда, а уже при agile и не получится.
Я во второй половине. Обдумывая вопрос я никак не мог принять первый кейс, потому что он не укладывается в моё мировозрение. Я сосредоточился не на финансах (как заметил Calc — это не дело тим лида — и я поддерживаю, тем более что в то время я вообще с финансами компании ни разу не работал, знал только в общих чертах).
Предполагал первопричину промахов в неудачной организации работы команды, спрашивал про методику работы, про предварительную приёмку.
Ещё раз хотел бы отметить, что это вопрос с собеседования, то есть ситуация вымышленная. Задача, проверяющая ход мыслей и наличие определённого набора soft-skills. На тот момент у меня не было некоторых из них. Например, тогда я ещё не общался с заказчиками напрямую. Сейчас я просил бы моего оппонента на собеседовании принять роль заказчика в этой игровой ситуации, чтобы выяснить его мнение как заказчика. Как он отреагировал бы на правду про 20%, что он вообще думает про откладывание частей работы «на потом», готов ли он запустить частично работающий проект. Заказчик в данном случае тоже часть команды и с ним тоже надо общаться.
Дополнительно ко всему, сейчас я бы ещё на стадии собеседования принял факт, что это УЖЕ МОЙ ПРОЕКТ. Так сказать, проникся к нему душой, мысленно прожил бы его целый год. И рассматривал его как кейс, на котором надо научиться и который нужно предотвратить в будущем. И как сказал fastwit — задокументировал его для себя, для каждого в команде и даже для заказчика :)
На ум приходит история
Один маклер продул на бирже миллион баксов. Пришёл с повинной головой, рассказал боссу как всё было, в чём именно он ошибся. Предложил уволить его. Обещал вернуть частями.
Босс сказал: «Вы только что получили образование за счёт компании. Ваша учёба стоила нам 1 000 000 долларов. Идите, работайте, применяйте полученные знания на практике.»rfvnhy
22.03.2017 17:30> «Вы только что получили образование за счёт компании. Ваша учёба стоила нам 1 000 000 долларов. Идите, работайте, применяйте полученные знания на практике.»
не лучший пример.
нет чёткого ответа была ли от менеджера положительная прибыль для компании и сколько раз, на каких суммах и какой % прибыли.
Если ему просто доверили 1кк и он их «продул» то виноват в 1ю очередь доверивший такую сумму человеку без опыта.
Если же у него был «рост», сначала доверяли по 20-30к, потом 100к, потом 500…
все работы были в "+", то дальше надо считать — возможно его предыдущая работа покрыла своей прибылью этот фейл, или близка к нему — тогда ответ начальника верный.
В общем снова нет конкретики.
D01
25.03.2017 09:52Нельзя ли привести пример функционала, который невозможно реализовать из-за плохой архитектуры?
vasiliysenin
27.03.2017 12:25Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново. Я, как кандидат на руководителя разработки, должен проанализировать ситуацию, принять решение, согласовать с заказчиком.
Так как это собеседование и ситуация гипотетическая, причём с не полной информацией, то надо показать как Вы умеете:
1) анализировать ситуацию
2) принимать решения
3) согласовывать с заказчиком
Так как по ситуации задана не полная информация, то надо её дополнить выгодными для Вас данными. Например исходя из того что компания занимается «разработкой программного обеспечения для веб и для мобильных приложений». Предположить что заказчик заказал сайт. А сайт можно уже запустить на восьмидесяти процентах функционала и в дальнейшем заказчик захочет чтобы его сопровождали и дорабатывали. А для сайта можно постепенно переводить сайт на новую архитектуру и доработать функционал до требуемого.vasiliysenin
27.03.2017 12:35И все эти действия из пунктов 1,2,3 надо делать с целью получения максимальной прибыли для компании разработчика. То есть надо предложить заказчику выгодные для него доработку сайта и разработку мобильного приложения к нему.(и заказчик конечно должен согласиться :) )
mizhgun
Единственный вывод, который я смог сделать из этого сообщения: от тим-лидов, бессвязно рефлексирующих в риторике Trainspotting, лучше держаться подальше всем участникам процесса.
copist
Вот ведь я ж норкоман-то :) Про Trainspotting не знал.
Ну, у меня было время порефлексировать, теперь делюсь опытом.
Как говорится — спонсор этого вечера — фраза «надо было тогда не так сказать».
Calc
Я вот до сих пор не понял почему тим лид отвечает за деньги.
За время — отвечает, за деньги это какой то цирк с конями.
Грамотный менеджер/финансист быстрее выбьет денег на доработки, нежели тех спец.
а по поводу заваленных сроков на 1/5 при оплате за каждую 1/4 почему не было видно на первых 3/5 что проблема уже есть?
При таком раскладе супервайзеру проекта нужно вставить люлей за то, что не проконтролировал, тим лиду вставить люлей за вытягивание сроков. А остальные — люди подневольные.