Вопрос с реального собеседования (6 лет назад)

Позиция: руководитель группы разработки, 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

Автор:

Источник