Предисловие

Нельзя сказать, что я очень прямо вообще такой матёрый веб-девелопер, но за свой очень насыщенный год в качестве профессионального разработчика прошёл сквозь огонь, лёд, пламя, медные трубы, и код в базе данных в исполнении индусов. Особенно большие впечатления от индусов. Но всё это меркнет по сравнению с заказчиками. Как выяснилось, самое сложное в разработке — это угодить всем тем людям, которые нанимают тебя и даже платят тебе деньги. Ты можешь до невозможности гордиться своим детищем, но ему то всё равно, чем вы там гордитесь. И за это время я узнал множество лайфхаков и тонкостей. До определенного момента времени думал, что все крутые парни знают все эти фичи, но в последнее время всё чаще убеждаюсь, что некоторые вещи всё же следует донести до масс.

Эпизод I: «Начало»

Вот сидите вы без дела, читаете статейки на каком-нибудь известном новостном ресурсе или делаете игрушки на Unity, и вдруг вбегает ваш менеджер и такой: «У нас новый проект, ребята, ухууууу». И убегает. Все, кто знает английский язык на разговорном уровне ](в данном случае я и мой тимлид), подрываются на месте, быстро сворачивают все свои хромы со статьями о валютных курсах и прочей бессмысленной шелухе, напяливают наушники с микрофоном и слышат уже до боли привычный звонок скайпа.

«Hi, Michael. I want to introduce you our team…»

Менеджер, ловко оперируя словами, заставляет клиента почувствовать всю серьёзность нашей компании. Он никогда не узнает, кто сколько выпил в воскресенье на корпоративе и почему на нашей таск-борде (обычная белая доска с маркером) очень много мата. Далее, после всяких капиталистических фамильярностей, начинается процесс обсуждения проекта. В этот момент тимлид включает запись звука в компьютере и записывает весь процесс обсуждения проекта. В последствии бедной девочке-менеджеру придётся сделать полную стенограмму этого разговора. В процессе обсуждения проекта заказчик высирает выдаёт все известные ему идеи, которые он только хочет видеть реализованными. Мы отвечаем ему, что приступим к подготовительной части проекта, и, довольные, заканчиваем разговор. Далее менеджер уходит делать стенограмму, а девелоперы возвращаются к чтению статей. Это последние спокойные часы, затишье перед бурей…

Эпизод II: «Snowballing»

После того, как девушка-менеджер окончила стенограмму и вместе с тимлидом выделила основные аспекты будущего проекта, вся команда собирается у таск-борды и обсуждает каждый пункт из этого длинного списка. Этот процесс называется фичекатом(от англ. feature cut — «отрезание» деталей). Все фичи, которые запросил клиент, обсуждаются и относятся в три группы:

• required/core features
• optional/useful features
• костыляble/useless features

В первую группу относят основные фичи, которые попросил заказчик. Это скелет проекта, основной функционал, который будет реализован на проекте. Во вторую группу входят фичи, которые не обязательны к выполнению для функционала сайта с нашей точки зрения и мы можем отказаться от них, если это будет технически сложно/невыгодно. Последняя группы — это те фичи, которые по нашему опыту абсолютно не нужны и даже могут создать сложности в будущем. Ко всему прочему, на основании анализа этих пунктов, можно добавить какие-то фичи во второй и третий пункт. Например жёсткая интеграция с какой-то определённой базой данных (Oracle DB) будет в третьем пункте. Зато в первом пункте появится такая фича, как «реализация работы с множеством других типов баз данных».

А где же ТЗ заказчика, спросите вы? Разве он его не присылал? Конечно присылал. В этот ТЗ заказчика мы вносим свои правки и предоставляем ему на подтверждение. Если он согласен — нам повезло. А если не согласен — будем уговаривать согласиться, пока он нас не задавит, и мы не прогнёмся. Ну, говнокодить так говнокодить, мы сделали всё, чтобы этого избежать.

Эпизод III: «Дивелапинг»

Проект набирает обороты! После окончательного утверждения ТЗ, его разбивают на таски (задачи) и выставляют эстимейты (сметы, оценки). Чем адекватнее требование, тем адекватнее эстимейт. Например, все фичи из третьего пункта будут неадекватно заэстимейчены. И это очень важно и правильно, об этом будет чуточку позже. Далее команда собирается, обсуждает общую архитектуру, распределяются таски и всё такое, короче говоря, работа кипит. Если в процессе заказчик вносит какие-то правки, их оценивают и тоже эстимейтят. О правках тоже чуть позже. Короче разрабы пашут аки кони, и всё у всех хорошо.

Эпизод IV: «Сдача проекта»

Тут может быть очень много проблем и вообще всего. Весь проект делается полностью по ТЗ и только по ТЗ. Больше документов, которые выставляют для вас цели, нет. Ни переписки, ни «я вам говорил по скайпу», ни «ну вот у них это сделано вот так, а вы вот не так, вообще». Ни-че-го. С другой стороны, всё должно быть строго по ТЗ. Именно для того, чтобы таких ситуаций не возникало, мы стенографируем общение с заказчиком и пересматриваем ТЗ, вносим правки. И всё равно, ядрён конь, эти ситуации возникают. Кто-то не то сделал, кто-то что-то не так понял и понеслось. Один раз мы получили письмо, в котором слово «f*ck» и производные составляли процентов 70-80 от всего текста. Дайте заказчику выругаться. Пусть выпустит пар. А дальше формируем новое ТЗ для «допиливания напильником»: стили подогнать, разукрасить как надо, SEO настроить и так далее. Выставляем эстимейт, скромненький, но обязательный, заказчик оплачивает и доводим всё до идеала. В конце концов 90% заказчиков довольны. Остальные 10% — заказчики из России или Украины.

Эпизод 5: «Империя наносит ответный удар»

Разработал? Так иди и поддерживай. Во-первых, на поддержку опять же выставляется эстимейт. В среднем, саппорт-тим одного проекта состоит из одного разработчика, он тратит на это 30 часов в неделю. Он копается в сайте, поднимает базу, если та падает, делает мелкие фиксы. Если намечается хоть какой-нибудь мало-мальски большой баг — сразу в эстимейт. В это время заказчик придумывает всё новые и новые фичи. Кто их будет делать? Мы! На каждую фичу — эстимейт. Поменять фотографию на сайте — эстимейт. Добавить в базу таблицу — эстимейт. Он хочет в нас плюнуть — эстимейт. Да-да-да, эстимейт на каждый плевок. Пусть платит за это деньги. Потому что если хоть раз дать ему плюнуть в нас бесплатно — он нас заплюёт до смерти. Деньги есть очень хороший сдерживающий фактор для заказчика, поэтому стоит давить именно на деньги. У нас в команде эстимейты выставляются часами, а один час стоит около 30-40 долларов. Заплатить 100 долларов за фотографию или лишний и очень бесполезный чекбокс? Да пожалуйста, сколько хотите! Любой каприз, но деньги заплатите. Вот так и живём. К сожалению, многие клиенты очень этим недовольны и некоторые вещи действительно можно и сделать бесплатно. Но это уже чисто индивидуально по отношению к клиенту, основываясь на том, какой он человек и с чем его едят. Иногда под хорошего клиента и прогнуться можно, но ни в коем случае никому нельзя давать намёка на то, что вы будете делать бесплатно.

Эпизод 6: «Возвращение к статейкам»

После прохождения через все эти круги разработки у заказчика иссякают идеи(в конце у вас получается какой-нибудь коммерческий проект с API, SDK, модулем для magento и woocommerce, двумя репозиториями на гитхабе и разработанным дизайном для кружки. Больше уже ничего не сделать. Остаётся только читать статьи до следующего проекта. С ужасом вспоминая времена становления компании, когда вы брали любые фриланс-проекты у всех подряд(даже у украинцев), и с наслаждением снова и снова рассматривать новый готовый проект, сделанный для какого-нибудь американца.

Небольшие советы для разработчиков: всегда очень долго, нудно и кропотливо разбиратей с заказчиком ТЗ. Пусть он напишет туда всё, что хочет и за всё заплатит. Только так и никак иначе. Потом начнется «я вот вам когда-то сказал, вот мы по скайпу говорили и вы сказали, что можно лалала». Только ТЗ.
Небольшие советы для заказчиков: в большинстве случаев вы сами не знаете, чего хотите. Наша компания представляет услугу по обработке ТЗ. Не бесплатно, как могло показаться, а за деньги. Просто эту сумму вы разбиваем в почасовку, когда просим какие-то деньги. Советую долго, нудно и кропотливо обсуждать ТЗ с вашими разработчиками, или же нанять программиста, который поможет составить вам уже готовое ТЗ основываясь на ваших идеях.

Спасибо за внимание!

P.S. Ничего личного к украинцам не имею, просто статистически проекты с заказчиками из жовто-блакитной проходят хуже всего. Прошу прощения, если вдруг кто-то оскорбился. Будем пить пиво и со смехом вспоминать все былые обиды.

Автор: PaulTG

Источник