История одного провала

У нас на заборе бумаге написано очень много букавок о том, как управлять проектами. Столько же, если не больше закорючек посвящено тому, какие истории успеха из этого выходили. Тошнотно, неинтересно, задолбало. Рассмотрим историю одного провала, это ведь всегда интересней и притягательней (видимо, в силу натуры человечьей больше злорадствовать, чем радоваться). Приступим.

В начале было желание

Рядовой проект. Не простой, но и не особо сложный. Дабы не уходить в дебри пальцетыканья, назовем его проект 1. С компанией А. Которая является исполнителем одного важного задания компании Б. Очень крупной, да еще и специфичной в своей продукции, а как следствие, очень любящей за свои большие деньги приносить большой мешок радости в виде доработок и согласований на голову тех, кто работал с нею. И есть представитель компании А по имени В, и есть его начальник Г. Туману напустили, грусть в головы читателя вселили, можно двигаться дальше.

Этап 1

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

Бегло ознакомившись с этим зверинцем, я отправляюсь в офис компании А, чтобы поговорить с В о том, чего же они на самом деле хотят. Часа за 4 формируется набор набросков интерфеса, логики работы программы, появляется понимание того, что мешанина умножений, вычитаний, делений и прочих скобок в экселе претендует на роль рассчета бизнес-процесса. И даже появляется понимание того, как это делать. Достигаются договоренности относительно реализации, сроков, оплаты — в бой. По прошествии некоторого времени появляется программа.

Межсезонье

Простой проект постепенно начинает дополняться осенизмами. Осенизм — это требование, которое появляется у заказчика в процессе работы над программой. Как правило, это данность. Я еще не встречал ни одного проекта из более 120 проектов по разработке веб, десктоп, встраиваемых систем и кода для микроконтроллеров, в котором бы он четко соответствовал изначальному ТЗ. Если вы верите в прешествие марсиан и в трех слонов на трех китах — то пожалуйста, можно так же слепо верить в фиксированное ТЗ. Но, как правило, во время работы всплывают нюансы, идеи, да и просто «тыдыдыщ забыл» — я, по крайней мере, привык. Но на каком то из этапов иетраций доделок я начал понимать, что они все больше и больше затрагивают бизнес-логику, и начал активно этот процесс сворачивать. Бизнес логика — краеугольный камень ПО, и если ее нет, то это проблема сродни падению метеорита по сравнению с разлитым кефиром, коим является «ой тут кнопочку». Мы договариваемся о втором этапе.

Этап 2. Путь к краху

На этом этапе В предлагает, а я соглашаюсь на то, что В, будучи программистом, который писал для компании А ПО, а потом перешел в штат, напишет новую бизнес логику на языке программирования. На каком — не важно, важно — отличном от моего. Да и это, собственно, не важно, если это только не брейнфак — языки примерно одинаковы, и при наличии документированного кода разобраться с тем, что делает программа, суть которой — обсчитать действия пользователя, достаточно просто. Как оказалось, это мне так казалось, уж извините за каламбур. Не буду осуждать манеру разработки ПО. Бывает всякое, видел разное. Самолично читал при реверс инжиниринге прошивки блока управления одного очень крупного автопроизводителя комменты, которые заставляли ржать в голос, а некоторые решения, примененные в этом ПО, приводили в ужас. И ничего — видимо, в продакшне (раз я это читал), и ездит в миллионах проданных авто. Важно другое. Дебаг кода, переписанного по правилам, занял в 4 раза больше времени, чем планировалось. Была даже крамольная мысль скопипастить код и сделать конвертор из структуры данных в тот набор переменных, а по итогам отработки кода — конвертировать обратно.

Немножко позволю вернуться к началу. Компания А делает продукт для Б. Очень крупной Б. К которой ходят периодически показывать промежуточный результат. Зачем — не понятно. Ибо после каждой встречи я получаю еще кучу требований к визуальному оформлению и логике взаимодействия с пользователем. С внесением новой логики в еще не отработанный код. С еще более урезанными сроками после каждой встречи. Поток детерменированного хаоса нарастает.

Как итог — сотрудник В отстраняется руководителем Г от работ, и Г берет дело в свои руки. Тоже спорный момент. Бизнес-логику я получил в виде кода as is. На сверке при передаче было очень много круглых глаз — у меня от того, что я узнавал, что мне не дали банальные требования к софту, которые были и, что самое главное, не были «супер_топ_секрет». У Г — когда он вникал в смысл творящегося в бизнес логике, которая была усложнена на несколько порядков от требуемого.

Бида, тоска и огорчение.

Итог?

Я замечательный программист. Я все сдаю вовремя. Всегда. Я не совершаю ошибок. Я пишу идеальный код. Все заказчики — скоты и олигофрены, не понимающе, как им повезло.

Вроде ничего не забыл. Так надо было бы закончить эту историю. Если бы я хотел поплакаться в жилетку. Но помните начало статьи? Давайте на примере факапа, а не истории успеха разберем то, что надо было делать. Все мы сильны задним умом, потому банального «надо было записать все требования в ТЗ, подписать договор и сидеть на жопе ровно после выполнения ТЗ» я писать не буду. Эта ошибка очевидна как божий день, да и ошибкой ее назвать сложно — помним о марсианах и слонах.

Ошибки

Отсутствие приезда перед началом второго этапа. Помните — на первом я приехал и мы проговорили работу. На втором я этого не сделал, будучи уверенным в том, что это то же самое, только в профиль. Как итог — я получил немало доработок «вот это передвинуть, а тут добавить».

Согласие на код вместо текстового задания. Одна из ключевых ошибок, даже страшнее первой. О это славное «я когда то….». У каждого есть это «когда то». Я тоже когда то ремонтировал автомобили. Даже был собственный сервис. И это не слабо помогает мне, когда на СТО мне начинают нести откровенную чушь. Но свойство нашей памяти таково, что мы помним хорошее, а плохое стирается. Да, я бросил автомобили потому, что отдавал все время работе, и просто сгорел. Тошнить стало. Но помню ли я то ощущение, когда тошнило? Неа. Это просто набор букав. Факт. Голый. И все. А вот бухалово по вечерам в компании ребят, покатушки, интересные проекты по тюнингу, забавные случаи — пишу и на лице улыбка, ей богу. Пройдет еще пяток лет, и может я вновь ввяжусь в автомобили. Как знать?
«Когда то» очень тесно связано с приятными воспоминаниями. И потому — кажется простым, забавным, интересным. И когда модель, которую обещал передать в работу, вдруг не работает, когда реальность тыкает тебя носом в то, что код надо дебажить (который, к слову, обнаружил уже после уязвимости по граничным условиям) — тогда да, как то на работу такую уже и не стоит приоритет. И радости нету. Никакой. Потому и логика мне была прислана с опозданием в 6 раз от заявленного.
А я — вислоухий дурак. Прекрасно осведомленный о том, что такое «я когда то кодил». Прекрасно знающий, что это самый ужасный заказчик. Но, тем не менее, поведшийся в очередной раз.

Согласие на доработки. А точнее — отсутствие их контроля. При работе я стараюсь выполнять не более 10% переделок от исходного задания перед промежуточной или финальной сдачей. Тут счет был потерян, мною же.

Согласие на урезание сроков. «планирование-проектирование-написание-тестирование». Чудес не бывает. Если сроки от заявленных урезаются в 2 раза, то это приводит к их увеличению в 2 раза. Так как что то в любом случае будет опущено, и приведет только к увеличению результирующего срока (а не срока, когда рапортуется о «готовности»).

Вот и все на сегодня. Надеюсь, опыт будет полезен камрадам. Доброй ночи.