Тот самый случай, когда мы за один месяц рожали то, что надо было делать три (не повторяйте, это больно)
Ачивка «Терминатор»: прибить проект, потому что проще заново
У нас есть внутренний продукт для оценки сотрудников. Он сменил три проджекта, три тимлида разработки, двух дизайнеров. Я была третьим проджектом в этой наследной цепочке.
Что пошло не так? Ну, в какой-то момент пришёл бизнес и сказал: чуваки, вот у нас замечательное ТЗ, его нужно сделать. Команда в первом составе собрала аналитику, прикинула список действий, заложила 15% времени на непредвиденное и приступила к разработке.
А в декабре бизнес сказал, что мы должны запуститься через месяц.
Мы катастрофически не успевали, стали выпускать поэтапно и седеть. В этот месяц родилось то, что мы очень вежливо называем MVP. Он был настолько прекрасен, что части бека выполнялись на фронте. Потому что фронтендер помогал, чем мог, и делал математику для обработки данных прямо в формах ввода этих данных.
Первый состав по каким-то личным причинам (возможно, кровью из глаз) не смог взять это на поддержку, сменились тимлид и проджект. Бизнес считал, что проект нормально работает, нормально поддерживается и всё с ним будет хорошо. И начал выкатывать новые запросы на фичи в нон-стоп режиме.
Второй тимлид выгорел и уехал в условный Гондурас.
Всё это время в команде был разработчик, у которого был гениальный план, что бы он сделал, если бы стал тимлидом. В какой-то момент его мечта сбылась. Он стал тимлидом. Тут нам как раз принесли новый блок с жёстким дедлайном в три месяца, надо было сделать новый продукт «Оценка навыков — 360°». На всё это у нас было времени с мая по июль.
Короче, мы посовещались и пристрелили к чертям весь проект.
Мечта была в том, чтобы написать его заново.
Что было
У нас внутри компании есть HR-платформа. Есть разные блоки: можно посмотреть заявки, нанять сотрудника, уволить сотрудника, посмотреть структуру и так далее. Один из блоков — оценка сотрудника. Она привязана к грейдам, а грейды — это зарплата. По сути, оценка — это грейдирование и перфоманс. Перфоманс — это насколько ожидаемый результат не совпадает с фактическим. Изначально был только этот модуль, там была сторонняя платформа.
Поначалу это всё смотрелось здорово, были гугл-формы, которые было весело заполнять и получать оценку сотрудников по перфомансу. На первую сотню это был космос, на 200 человек тоже нормально, но на 3000 сотрудников внезапно объём стал давить. Обработкой всего этого занимался подрядчик. Подрядчик оказался малоповоротливым. В динамические процессы он не был готов встраиваться.
Следствий сразу три:
- Доработки под нас стоили очень много. А доработок надо было много, потому что процесс постоянно менялся вместе с компанией и ростом.
- Появилось очень много ручных процессов. Надо было из нашей системы переложить в гугл-файлик, добавить вопрос, выгрузить и отправить им, подзабрать результаты.
- Всё это рождало сложности и с хранением. Результаты лежали не в единой базе данных, а в куче внешних источников.
«Разбираем и делаем заново» № 1
Тогда мы решили собрать процесс как продукт и поставили на это команду. Стек PHP (symfony), Angular, PostgreSQL. Уже рассказывала в начале — мы долго запрягали, потом нам дали месяц срока, мы рванули и родили MVP.
И в один прекрасный день у нас поменялась (а по факту практически появилась) единая для компании система грейдирования. Оказалось, что модуль оценки № 1 вообще не готов к такому.
Собрали новые требования и поняли, что никаким образом инструмент не подстраивается под процесс.
Как вы уже знаете, это потому что он был MVP. Проект развивался достаточно своеобразно. По сути, мы сначала сделали MVP с максимально простым потоком: добавить сотрудника, добавить вопросы для оценки, посчитать среднее значение. Мы думали, что дальше будут только доработки фич, и тогда проблем бы не было. Но мы не учли его масштабирование. Архитектура оценки не предполагала, что, например, математика в разных вопросах может считаться по-разному или что будет отдельный банк навыков и скиллсетов. То есть MVP получился, с одной стороны, примитивным, а с другой стороны — неповоротливым для любых изменений и связей с другими частями экосистемы.
Тогда, в начале, мы не переделали его, а, по сути, построили опорную систему костылей. Что ещё подлило масла в огонь — это смена дизайна. При первой итерации мы на середине пути стали изменять макеты. То есть на момент изменений часть разработки уже была сделана. Тогда это решение казалось оправданным: лучше больше времени потратим на дизайн, чтобы было удобнее, понятнее и красивее для пользователя. Но нет, уже позже стало понятно, что ни одно «красиво» не перевесит «попробовать здесь и сейчас».
Что ещё хуже — на проекте менялись менеджеры. При старте проекта команда разработки HR была молодая и только формировалась. На момент прихода большого проекта мы умели делать относительно несложные таблицы, сбор данных, простые интеграции и связи между частями продукта. Ни разработка, ни менеджеры были не готовы к созданию большого продукта. Поэтому никто и не задался вопросом: «А что будет дальше MVP?» Плюс команда ещё формировалась, были и плохо выстроены внутренние процессы, и мало ресурса, и банальное «мы не знаем, как это делать, будем на ощупь».
Вносить изменения было тяжело. Вся архитектура была построена под один продукт: там вопросы, одинаковая математика их обработки и одинаковый результат. И всё это было в хардкоде. Да, можно было изменять вопросы и последовательность, но методология оставалась одна и та же. А в новом продукте все правила становились гибкими, и их надо было вынимать из хардкода. В разных командах появлялись разные процессы (а они тоже были захардкожены). Например, в перфомансе есть этап селф-ревью, который блочит переход к следующим шагам. Ты сначала должен написать, что получилось или не получилось, а уже потом респонденты оценивают тебя по результатам. В другом процессе селф-ревью может быть необязательным и никогда не будет стопить следующие шаги.
В общем, как можно догадаться, это был проект с необычной архитектурой, необычными подходами к разработке, но достаточно стандартным результатом.
И вот этот результат не вписывался в новые требования для грейдирования.
Как же так, чёрт побери?
Всё дело в сроках. Почему первый вариант был чудовищем с беком на фронте, я уже примерно описала.
Когда бизнес попросил добавить одну маленькую фичу, это было легко решить костылём.
Потом костылей становилось больше. Ещё больше. В итоге то, что заняло бы на нормальном проекте три-четыре часа, решалось за неделю. Переделывать кодовую базу времени не было, надо было вбивать костыли.
В общем, никогда так не делайте.
«Разбираем и делаем заново» № 2
До первой оценки по грейдам с новым блоком осталось три месяца.
Надо было впилить ещё столько же функционала, сколько уже было.
Шансов это сделать вовремя не было никаких. Продукт дорос до стадии, когда не подходил. Это было больно. Рефакторингу он не поддавался, просто разобраться в том, что происходит в коде, уже было приключением для психики.
В общем, тут мы его пристрелили, потому что оценка показала, что это тот самый случай, когда писать с нуля быстрее, чем дорабатывать.
Мы пошли делать всё с нуля второй раз. Стали смотреть гибкость процесса. Сделали больший упор на добавление настроек, дополнительных этапов. Сломали всё, что было до. Архитектуру (точнее, корневая архитектура была правильная, а вот дальше оно обрастало спагетти), то, как собирались данные. Всё разломали и собрали заново с учётом гибкости. В прошлый раз на каждую новую фичу костылили — и как итог не успели. А здесь начали всё заново и благодаря этому уложились в сроки.
По идее, ещё на первых этапах нужно было закладывать не только простоту, но и гибкость, чтобы при успешном успехе продукт можно было масштабировать. Это сэкономило бы время и дало бы нужную простоту первого подхода.
В общем, потом мы всё же всё правильно доделали. Сейчас оно работает на проде, нормально поддерживается и только начинает зарастать илом и ракушками, а не состоит из них. Ну, а я считаю, такая ачивка пристреливания того, что проще написать заново, должна быть у каждого менеджера.
