Что нужно учитывать менеджеру, чтобы не переделывать проект с нуля

Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.

Всем привет, меня зовут Леонид Неугодников. Последние два года руковожу разработкой CRM-системы для продажи недвижимости в Штатах. Специализируюсь на веб-разработке и бэкенде, работаю в основном с высоконагруженными продуктами.

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

Мой коллега, Денис Шаматажи, дополнил некоторые пункты с точки зрения своего 6-летнего опыта в менеджменте продуктовых команд.

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

Несогласованный дизайн

UX-проектирование часто упускают из виду на этапе анализа приложения. Казалось бы, дизайн не самый важный момент, о котором надо думать в начале. Но несогласованность в UI может привести к постоянным редизайнам, поэтому отложить обсуждение внешнего вида приложения на более поздние стадии будет рискованно. Когда на старте у команды нет ясности, что будет происходить в дизайне, можно столкнуться с проблемами.

Можно подумать, что дизайн и бэкенд мало связаны, но на деле бэкенд — это в первую очередь о данных, которые есть в приложении. И вот данные связаны с дизайном непосредственно.

У меня было множество ситуаций, когда дизайнер нарисовал фантастический макет. Потом разработчики пытаются засунуть реальные данные в готовый шаблон, и выглядит это все, мягко говоря, так себе.

Как-то мы делали приложение для аренды яхт. Дизайнер создал шикарную страничку с информацией о яхте и доступных датах бронирования.

А затем мы начали вытаскивать у провайдера реальные данные, прикручивать их, и я понял, что это абсолютно не вяжется с тем, что нарисовал дизайнер. Геоданные некрасиво отображались, размеры фотографий реальных яхт не соответствовали нарисованному шаблону. И таких проблем появилось огромное количество.

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

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

Заказчики из сферы бизнеса часто хотят наблюдать за работой с дизайном, ведь это внешний вид, своего рода визитная карточка и статус. При этом клиент любит смотреть на красивый UI, но не готов разбираться с UX.

Поэтому РМ тянет, долго не согласовывает дизайн, стараясь сделать все максимально точно и красиво. Затем менеджер приносит готовый макет заказчику и слышит в ответ:

— Мне не нравится, давайте поменяем вот здесь.

РМ возвращается с правками к разработчикам, но те не согласны:

— Так делать нельзя: это будет хуже, дольше и так далее.

Возникает заведомо проигрышная ситуация. Если уговорить команду на правки, работа усложнится и растянется во времени. При постоянных уступках клиенту к вам однажды придут разработчики и скажут, что технического долга накопилось уже на полгода.

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

Как договориться с заказчиком

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

Например, мы сразу созваниваемся с лидами мобильной, бэкенд и дизайн-команды и быстро брейнстормим какой-то результат, чтобы получился наглядный набросок: нарисованный от руки, в Balsamiq или в Miro.

Глядя на макет, бэкенд поймет, в какую сторону двигаться, а мобильная команда увидит, что нужно проектировать. И все уже начнут что-то делать.

С нарисованным макетом идем к заказчику, согласовываем информационную архитектуру, расположение и так далее. Как только обсудили и внесли корректировки, развиваем это вместе с командой. Сделали какую-то итерацию дизайна — показываем заказчику.

Обычно клиент активно соглашается с какими-то UX-решениями. К тому моменту, когда вы сверху на UX делаете красивую картинку с анимациями и полутонами, заказчик уже уложил эту структуру у себя в голове и она не вызывает отторжения. Правки, если и будут, то не такими, чтобы сильно повлиять на информационную архитектуру, которую выстроили бэкенды.

Часто за внешним видом, особенно за UX, выстраивается какая-то логика внутри приложения, которую важно понимать, чтобы сделать все правильно. При работе над мобильным приложением разработчикам помогает, если они получают схему всех возможных экранов приложения и того, как пользователь перемещается с экрана на экран. Глядя на такую схему, специалист понимает, какие данные нужны, в каком виде их отдавать, какие могут быть технические ограничения. Например, где лучше сделать через push-уведомления, а не подгружать данные по запросу. Это сильно облегчает работу бэкенда.

Неучтенные ограничения

Недостаток аналитики, планирования, игнорирование возможных ограничений системы, того, что есть банальное network input/output и его ограничения — это все влетает в копеечку в ходе проекта. Если мы недостаточно хорошо провели анализ, в процессе работы упремся в технические ограничения и придется переделывать.

Расскажу на нашем примере, как могут повлиять на проект технические ограничения. В нашем приложении есть функция для агентов по продаже недвижимости: можно подвязать аккаунт в Google. Потом мы запрашиваем определенный permission и получаем доступ к почте наших клиентов. Если агенту приходит сообщение, что где-то на стороннем сервисе зарегистрировался лид для него, мы сразу читаем это сообщение, парсим его особым образом и загоняем лида к нам в CRM.

И тут я допустил промах. Мы не учли ограничения платформы, не провели достаточной аналитики, поэтому реализовали всю работу фичи через webhook. Что такое webhook? Например: вам пришел новый email. Google шлет запросы на наши сервера и сообщает, что у клиента появилось новое письмо, читай.

В какой-то момент клиентов стало много и запросы по webhook начали приходить в запредельных количествах: сотни тысяч в день. Сервера ложились, а мы не могли понять, в чем дело: количество пользователей то же, количество данных, которое они гоняют в приложении, то же самое, лидов больше не стало. Почему виснет приложение и все сервера загружены на 95%? У нас ушло еще какое-то время на investigate, чтобы понять причину. Потом мы всю эту систему переписывали, и это заняло еще месяца полтора.

Что учитывать при анализе

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

На старте у тебя есть просто user и admin, потом выясняется, что будет еще и суперадмин, а внутри будет user и модератор. Пользовательские роли могут показаться чем-то простым, но в коде это приводит к неприятным изменениям и множеству лишней работы.

Будем ли интегрировать стороннее решение. Проблема, похожая на нашу с веб-хуками Google, может произойти не только с webhook и не только с Google. Я видел много ситуаций, когда интегрировали сторонние решения, и все шло не так, как ожидали. В итоге спринты завалены, ожидания клиента разрушены. Поэтому всегда учитывайте возможные ограничения платформы и делайте аналитику перед интеграцией.

Есть ли у нас user-generated content. Контент, который генерируют пользователи, обязательно надо учесть в коде и на дизайне. Иначе все это будет выглядеть и работать отвратительно.

Яркий пример из опыта: брокер на страничке своего сайта, который мы для него делаем, может задавать оценку для дома, показывая, насколько выгодна эта сделка. В приложении выгодность считается автоматически: оценка выставляется в сравнении с общей ценой на рынке.

Параллельно с автоматическим оцениванием мы дали возможность брокерам заходить и что-то менять. В итоге ты заходишь к брокеру на сайт, а оценки выглядят максимально неправдоподобно: весь сайт как будто завален выгодными сделками.

С одной стороны, это не наша вина, но с другой — именно такие действия мешают нашим клиентам больше и лучше продавать. И мы, как команда продукта, должны это отследить и сделать так, чтобы это все работало иначе, чтобы они даже изначально не могли сделать такой ошибки.

Поэтому, когда появляется какой-то user input — возможность для пользователей что-то менять в вашей системе, — всегда надо думать, к чему это приведет и что с этим потом делать.

Незафиксированные изменения

При всем уважении к заказчикам нужно стараться не особенно верить им на слово. Бывают разные ситуации. Например, мы параллельно работаем над двумя задачами и я говорю клиенту:

— Слушай, мы не успеем эту задачу сделать завтра, потому что у нас две задачи одновременно. Давай мы первую сдадим в пятницу, а вторую — через неделю.

Клиент говорит:

— Нет, бросай пока первую задачу, а делай сразу вторую, она приоритетнее.

Мы соглашаемся, успеваем, потом делаем баг fix, еще что-то, и первая задача затягивается недели на две.

В этот момент появляется клиент и спрашивает:

— А почему вы так затянули? Значит так, я иду на performance review, звоню твоему руководителю — и будем говорить, насколько вообще ты справляешься.

РМ пытается возразить:

— Но мы же обсуждали, что можно эту задачу перенести.

А клиент отвечает:

— Я имел в виду один день, а вы затянули на две недели.

Такая ситуация возникает постоянно и становится очень проблемной, когда заказчиков много, проект растет, а команда увеличивается.

Тут уже могут случаться ситуации, когда вас спрашивает CEO:

— А где эта фича?
— Продакт-менеджеры сказали, что ее делать не нужно, и мы ее не делали.
— Как это сказали, что не нужно? — СЕО идет к продактам, а те отвечают, что такого не говорили.

В итоге разработка оказывается «крайней» просто потому, что это один из последних пунктов в создании продукта. Когда вы приходите к концу и на выходе продукт не соответствует видению клиента, то, конечно же, крайними будут разработчики, потому что именно они столкнутся с фрустрацией заказчика.

Кому и как говорить об изменениях

Может быть так, что вы согласовали и даже зафиксировали изменения с одним заказчиком, но другой об этом не знает. Поэтому все, что представляется важным, лучше записывать и рассылать на всех стейкхолдеров.

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

О чем информировать стейкхолдеров:

• любые митинги, связанные с планированием;
• обсуждение фич;
• приоритизация задач;
• согласование дизайна;
• изменение скоупа.

Любая часть, которая касается изменения времени, стоимости или скоупа — это повод сразу поставить в известность стейкхолдеров. Удобнее всего рассылать follow-up по email и в конце делать приписку: «Если у вас возникают какие-то вопросы, дайте мне знать. Если вопросов не последует, мы будем планировать начало работ с такого-то числа». На следующий день можно еще раз написать: «Так как я не получил от вас ответа, мы начинаем разработку такого-то числа».

Важный момент по поводу версионности: что бы мы не показывали клиенту — документ, дизайн, презентации, какие-то материалы, в обязательном порядке поддерживайте версионность на уровне ссылок.

Например, скидываете клиенту ссылку на материалы в Dropbox, напишите, что это — «Презентация 1, итерация 28 марта». На следующий день клиент захотел что-то поменять, вы пишете: «Итерация 29 марта». При таком подходе заказчик всегда может посмотреть, что было раньше.

И если он спросит: «Почему так много итераций?», вы можете поднять предыдущие версии и сказать: «Ты тут попросил это поменять, вот изначально так было задумано, а 7 итераций провели только потому, что двигаем иконки». Это хороший point.

Технический долг

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

Самое простое определение понятия «технический долг», это — осознанное компромиссное решение. В какой-то момент вы берете и сознательно пишете что-то не очень хорошо, чтобы запуститься как можно быстрее. Потом вы, конечно, планируете все переписать, но чем дольше работаете, тем больше видите, что под видом компромиссных решений в системе скапливается огромное количество постоянных вещей.

У нас в приложении сейчас много кусочков кода, о которых мне говорили: «Давай сначала проверим гипотезу, а потом все это перепишем». В итоге неделю пишем код, проверяем гипотезу, фича со скрипом работает, а на переписывание никто времени не дает.

Техдолг с точки зрения кода — это просто плохо написанный модуль, который работает непредсказуемо или его трудно расширять. У нас бывали ситуации, когда мы писали фичу на скорую руку, чтобы «проверить гипотезу». И вот гипотезу проверили, все хорошо, но в какой-то момент я вижу, что 15% запросов по этому модулю приводят к deadlock, когда два процесса одновременно пытаются обновить одни и те же данные. И получается, что один обновляет, а второй ничего не делает, потому что данные заняты.

У нас такой модуль действовал очень нестабильно. Как только мы пытались внести изменения, например добавить новое поле, все становилось непредсказуемым, и уходило много времени, чтобы с этим работать. Поэтому было правильно в какой-то момент потратить 15–20 часов и даже половину спринта, чтобы решить вопрос.

Мне нравится практика code freeze, когда перед Новым годом остается свободный спринт без релиза, на котором вы решаете все накопившиеся проблемы и разбираетесь с техдолгом,

Еще одна проблема — это накопление ненужных данных. Мало кто заботится о data cleaning policy и всех этих штуках, хотя через 3–4 года существования продукта база данных всегда заполняется кучей мусора: несуществующие пользователи, неактуальный контент, картинки без ссылок. И все это надо чистить.

Допустим, вы платите за сервер 300 долларов, храните на нем данные, и все работает достаточно неплохо. В какой-то момент из-за мусора данных станет слишком много, поэтому они начнут дольше отрабатывать. Так работает база данных: больше данных, дольше искать. Это скажется либо на производительности приложений, либо на скорости взаимодействия пользователя с ним. И все это создаст плохую общую картинку.

Я уверен, что никто с самого начала не планирует data cleaning policy, если это не какой-то серьезный энтерпрайз. Чаще всего думают так: «Займемся этим потом». Такие ситуации обычны, ведь цель разработки — чтобы бизнес поскорее начал работать и приносить деньги.

Поэтому нормально, что техдолг есть, плохо с ним не разбираться. Накопившийся техдолг приведет к проблемам: придется масштабировать базу данных и платить больше за хранение, будут слишком долго делаться back-ups, а значит, появится риск потерять важные чувствительные данные.

Как обосновать клиенту работу с техдолгом

Решение техдолга — важное условие здоровья проекта. Я объясняю этот факт заказчику через стоимость и эстимейты:

1. Когда клиент спрашивает: «За сколько мы сможем это сделать?» — я говорю, что наличие техдолга в каком-то из модулей уменьшает шанс попадания в стоимость. Мы пообещаем, а потом окажется, что надо кусок переписать, потому что в целом его нельзя модернизировать. Например, когда все расписано на switch case и не работает. Поэтому я честно отвечаю, что из-за техдолга мы будем закладывать больше.
2. Далее говорю, что, если мы потратим, допустим, неделю на работу с техдолгом, потом в среднем наши эстимейты будут ниже, потому что эта часть кода станет более предсказуемой и делать ее будет проще.
3. С уменьшением техдолга снизится количество багов, в итоге клиент все равно сэкономит.

Такая мотивация работает со всеми заказчиками почти в 100 % случаев.

Краткий итог

Оправдать ожидания клиента и не переделывать работу с нуля помогают несколько факторов:

• Согласование дизайна с клиентом и командой.
• Понимание ограничений еще на старте проекта, а не в середине работы.
• Фиксация любых изменений времени, стоимости или скоупа.
• Правильное информирование стейкхолдеров.
• Работа с техдолгом и обоснование этой работы заказчику.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU