Ачивка «Терминатор»: прибить проект, потому что проще заново
У нас есть внутренний продукт для оценки сотрудников. Он сменил три проджекта, три тимлида разработки, двух дизайнеров. Я была третьим проджектом в этой наследной цепочке.
Что пошло не так? Ну, в какой-то момент пришёл бизнес и сказал: чуваки, вот у нас замечательное ТЗ, его нужно сделать. Команда в первом составе собрала аналитику, прикинула список действий, заложила 15% времени на непредвиденное и приступила к разработке.
А в декабре бизнес сказал, что мы должны запуститься через месяц.
Мы катастрофически не успевали, стали выпускать поэтапно и седеть. В этот месяц родилось то, что мы очень вежливо называем MVP. Он был настолько прекрасен, что части бека выполнялись на фронте. Потому что фронтендер помогал, чем мог, и делал математику для обработки данных прямо в формах ввода этих данных.
Первый состав по каким-то личным причинам (возможно, кровью из глаз) не смог взять это на поддержку, сменились тимлид и проджект. Бизнес считал, что проект нормально работает, нормально поддерживается и всё с ним будет хорошо. И начал выкатывать новые запросы на фичи в нон-стоп режиме.
Второй тимлид выгорел и уехал в условный Гондурас.
Всё это время в команде был разработчик, у которого был гениальный план, что бы он сделал, если бы стал тимлидом. В какой-то момент его мечта сбылась. Он стал тимлидом. Тут нам как раз принесли новый блок с жёстким дедлайном в три месяца, надо было сделать новый продукт. На всё это у нас было времени с мая по июль.
Короче, мы посовещались и пристрелили к чертям весь проект.
Мечта была в том, чтобы написать его заново.
Что было
У нас внутри компании есть HR-платформа. Есть разные блоки: можно посмотреть заявки, нанять сотрудника, уволить сотрудника, посмотреть структуру и так далее. Один из блоков — оценка сотрудника. Она привязана к грейдам, а грейды — это зарплата. По сути, оценка — это грейдирование и перфоманс. Перфоманс — это насколько ожидаемый результат не совпадает с фактическим. Изначально был только этот модуль, там была сторонняя платформа.
Поначалу это всё смотрелось здорово, были гугл-формы, которые было весело заполнять и получать оценку сотрудников по перфомансу. На первую сотню это был космос, на 200 человек тоже нормально, но на 3000 сотрудников внезапно объём стал давить. Обработкой всего этого занимался подрядчик. Подрядчик оказался малоповоротливым. В динамические процессы он не был готов встраиваться.
Следствий сразу три:
- Доработки под нас стоили очень много. А доработок надо было много, потому что процесс постоянно менялся вместе с компанией и ростом.
- Появилось очень много ручных процессов. Надо было из нашей системы переложить в гугл-файлик, добавить вопрос, выгрузить и отправить им, подзабрать результаты.
- Всё это рождало сложности и с хранением. Результаты лежали не в единой базе данных, а в куче внешних источников.
«Разбираем и делаем заново» № 1
Тогда мы решили собрать процесс как продукт и поставили на это команду. Стек PHP (symfony), Angular, PostgreSQL. Уже рассказывала в начале — мы долго запрягали, потом нам дали месяц срока, мы рванули и родили MVP.
И в один прекрасный день у нас поменялась (а по факту практически появилась) единая для компании система грейдирования. Оказалось, что модуль оценки № 1 вообще не готов к такому.
Собрали новые требования и поняли, что никаким образом инструмент не подстраивается под процесс.
Как вы уже знаете, это потому что он был MVP. Проект развивался достаточно своеобразно. По сути, мы сначала сделали MVP с максимально простым потоком: добавить сотрудника, добавить вопросы для оценки, посчитать среднее значение. Мы думали, что дальше будут только доработки фич, и тогда проблем бы не было. Но мы не учли его масштабирование. Архитектура оценки не предполагала, что, например, математика в разных вопросах может считаться по-разному или что будет отдельный банк навыков и скиллсетов. То есть MVP получился, с одной стороны, примитивным, а с другой стороны — неповоротливым для любых изменений и связей с другими частями экосистемы.
Тогда, в начале, мы не переделали его, а, по сути, построили опорную систему костылей. Что ещё подлило масла в огонь — это смена дизайна. При первой итерации мы на середине пути стали изменять макеты. То есть на момент изменений часть разработки уже была сделана. Тогда это решение казалось оправданным: лучше больше времени потратим на дизайн, чтобы было удобнее, понятнее и красивее для пользователя. Но нет, уже позже стало понятно, что ни одно «красиво» не перевесит «попробовать здесь и сейчас».
Что ещё хуже — на проекте менялись менеджеры. При старте проекта команда разработки HR была молодая и только формировалась. На момент прихода большого проекта мы умели делать относительно несложные таблицы, сбор данных, простые интеграции и связи между частями продукта. Ни разработка, ни менеджеры были не готовы к созданию большого продукта. Поэтому никто и не задался вопросом: «А что будет дальше MVP?» Плюс команда ещё формировалась, были и плохо выстроены внутренние процессы, и мало ресурса, и банальное «мы не знаем, как это делать, будем на ощупь».
Вносить изменения было тяжело. Вся архитектура была построена под один продукт: там вопросы, одинаковая математика их обработки и одинаковый результат. И всё это было в хардкоде. Да, можно было изменять вопросы и последовательность, но методология оставалась одна и та же. А в новом продукте все правила становились гибкими, и их надо было вынимать из хардкода. В разных командах появлялись разные процессы (а они тоже были захардкожены). Например, в перфомансе есть этап селф-ревью, который блочит переход к следующим шагам. Ты сначала должен написать, что получилось или не получилось, а уже потом респонденты оценивают тебя по результатам. В другом процессе селф-ревью может быть необязательным и никогда не будет стопить следующие шаги.
В общем, как можно догадаться, это был проект с необычной архитектурой, необычными подходами к разработке, но достаточно стандартным результатом.
И вот этот результат не вписывался в новые требования для грейдирования.
Как же так, чёрт побери?
Всё дело в сроках. Почему первый вариант был чудовищем с беком на фронте, я уже примерно описала.
Когда бизнес попросил добавить одну маленькую фичу, это было легко решить костылём.
Потом костылей становилось больше. Ещё больше. В итоге то, что заняло бы на нормальном проекте три-четыре часа, решалось за неделю. Переделывать кодовую базу времени не было, надо было вбивать костыли.
В общем, никогда так не делайте.
«Разбираем и делаем заново» № 2
До первой оценки по грейдам с новым блоком осталось три месяца.
Надо было впилить ещё столько же функционала, сколько уже было.
Шансов это сделать вовремя не было никаких. Продукт дорос до стадии, когда не подходил. Это было больно. Рефакторингу он не поддавался, просто разобраться в том, что происходит в коде, уже было приключением для психики.
В общем, тут мы его пристрелили, потому что оценка показала, что это тот самый случай, когда писать с нуля быстрее, чем дорабатывать.
Мы пошли делать всё с нуля второй раз. Стали смотреть гибкость процесса. Сделали больший упор на добавление настроек, дополнительных этапов. Сломали всё, что было до. Архитектуру (точнее, корневая архитектура была правильная, а вот дальше оно обрастало спагетти), то, как собирались данные. Всё разломали и собрали заново с учётом гибкости. В прошлый раз на каждую новую фичу костылили — и как итог не успели. А здесь начали всё заново и благодаря этому уложились в сроки.
По идее, ещё на первых этапах нужно было закладывать не только простоту, но и гибкость, чтобы при успешном успехе продукт можно было масштабировать. Это сэкономило бы время и дало бы нужную простоту первого подхода.
В общем, потом мы всё же всё правильно доделали. Сейчас оно работает на проде, нормально поддерживается и только начинает зарастать илом и ракушками, а не состоит из них. Ну а я считаю, такая ачивка пристреливания того, что проще написать заново, должна быть у каждого менеджера.
Комментарии (36)
Leetc0deMonkey
11.07.2023 07:11+21А в декабре бизнес сказал, что мы должны запуститься через месяц.
Интересно, вот если я приду например на стройку, стукну кулаком по столу и скажу "всё должно быть сделано через месяц, а не три"... там все послушно гривами закивают и побегут делать за месяц, или айтишники в этом плане уникальны?
kommandor
11.07.2023 07:11+5Это так и работает
Leetc0deMonkey
11.07.2023 07:11+3Не работает. Буду послан найух, потому что срок сдачи XX/YY. И будут правы.
ildarz
11.07.2023 07:11+5Работает-работает, просто кулаком стукнули чуть раньше, когда срок сдачи XX/YY ставили. Собственно отсюда (в том числе) и вечные переносы реальных сроков сдачи строек.
Leetc0deMonkey
11.07.2023 07:11+1просто кулаком стукнули чуть раньше, когда срок сдачи XX/YY ставили.
Ну так тогда какие претензии? А в вышеописанной истории "бизнес", похоже, в одностороннем порядке поменял сроки, и ничего ему за это не было.
ildarz
11.07.2023 07:11Ну как бы да, сначала заказчик "в одностороннем порядке" ставит срок завершения стройки в привязке к какой-нибудь памятной дате (чемпионату мира там, или дню рождения гендира заказчика), а потом исполнитель "в одностороннем порядке" сдает позже. Или не сдает вообще. А претензии - там по-разному бывает. :)
Conung_ViC
11.07.2023 07:11+9вы никогда заброшенные стройки посреди города не видели?
Эт вот как раз те, что не успели за месяц... а на три у них денег уже не было...
cat_chi
11.07.2023 07:11+6Есть два стула (простите).
Вы стучите кулаком и говорите "релизим это дерьмо завтра" и получаете кривой багованный релиз, который потом пару месяцев допиливается в режиме "прод горит, жопы горят, всё горит, тимлид седеет не по дням, а по часам".
Вы вежливо спрашиваете, сколько времени нужно разработчикам, вздыхаете, умножаете их ответ на три, и терпеливо ждёте. На выходе не получаете вообще ничего.
Как это работает? Магия :)
P.S. Утрирую, конечно. Но зачастую именно так и происходит
outlingo
11.07.2023 07:11Попробуйте отказаться от мантры что разработчики это священные коровы которых обижать (и уж тем более наказывать) нельзя. Человек должен отвечать за свои слова. Тогда в описании второго случая внезапно второе предложение исчезает, а результат получается
nin-jin
11.07.2023 07:11+1Вам бы архитектора нормального. Я бы сделал это
с трёх нотза три дня. Пруф. Даже с учётом переучивания ребят на более другие технологии вышло бы не более месяца в неспешном режиме. И не пришлось бы потом никого пристреливать.
anone1947389
11.07.2023 07:11+14Несите таблетки, дед опять бредит!
Зачем пиарить свою недоподелку в приличном обществе? Идите на пикабу, или дтф, там аудиторию свою найдешь.
nin-jin
11.07.2023 07:11+3А приличное общество - это там, где проект пилится на разросшемся шаблонизаторе и звездолёте с детскими болезнями, проезжается по сроками, а потом по 3 раза ещё переписывается с нуля? Что-то мне дурно, скорее же таблетки несите.
anone1947389
11.07.2023 07:11Опять же, это лучше, чем брать корявое нечто типа мола, тратить годы на допил, что бы хоть как-то можно было работать, и все равно возвращаться к шаблонизаторам и звездолетам, потому что скорость разработки выше на порядки. Так что да, это очень приличное общество программистов с опытом, и всяких денисов поповых тут не любят. Разве что посмеяться.
nin-jin
11.07.2023 07:11+1То есть $mol вы не пробовали, но мнение имеете. Вопросов больше не имею.
anone1947389
11.07.2023 07:11Если бы я пробовал каждую сомнительную поделку от людей, которые не умеют во фреймворки, у меня бы не было времени работать :)
Не обязательно пробовать всякое- по запаху становится ясно. Если же тебе надо еще и попробовать, дело твое, у меня другие интересы.
nin-jin
11.07.2023 07:11+1А вот если бы саморазвивались, читали статьи, пробовали разные подходы, объективно их оценивали, и лучшие из них внедряли, то у вас была бы куча свободного времени, которое вы могли бы без сожаления тратить даже на сомнительные, на первый взгляд, вещи.
anone1947389
11.07.2023 07:11То, что я не трачу на сомнительные, не на первый взгляд, а именно сомнительные вещи, и есть результат саморазвития, чтения статей, новых подходов, объективной оценки. Все это позволяет видеть, что мол- бесполезный мусор. Как болгенос ос. Как тысячи иного мусора.
Не, если это поделка студента, еще может быть, как какое-то самообразование. Но зачем впихивать продукты своей жизнедеятельности людям?
Пока, было потешно.
chilicoder
11.07.2023 07:11+16Судя по
сменились тимлид и проджект. Бизнес считал, что проект нормально работает
с жёстким дедлайном в три месяца,Не выстроен рабочий баланс между тимлидами и бизнесом.
Вангую причины:
Бизнес считает, что лучше знает, сколько длится разработка
Бизнес не верит оценкам тимлидов
Тимлиды "плывут по течению", собирают космолеты на принятом в компании стеке с самого начала, а не предлагают реальные mvp с очень быстрой проверкой гипотез
Тимлиды слишком мягкие, чтобы докладывать бизнесу реальное положение дел
Тимлиды боятся говорить "нет"
В компании нет культуры реального планирования (это когда реально все учатся оценивать, а не делают вид. Это больно и страшно вначале)
cat_chi
11.07.2023 07:11Вангую причины:
Так себе тимлиды и так себе менеджмент C-уровня.
А нормальных тимлидов найти – тот ещё квест. С нормальным менеджментом проблем ещё больше
sedovamargarita Автор
11.07.2023 07:11+2Да, амбиций команды было больше, чем опыта в подобных проектах. Можно было назвать пост «очередной Титаник, который мы проглядели», но тут хотя бы всё хорошо закончилось. Да, мы сыграли в Брюса Всемогущего и больно стукнулись (выжатая команда, полувыпущенный продукт, вторая переделка с нуля). Но этот опыт дал то ценное, что даёт возможность нормально двигаться дальше и не совершать подобных ошибок.
chilicoder
11.07.2023 07:11Если этот "титаник" еще и "очередной", я бы посоветовал вашему менеджменту от бизнеса и теха сесть и честно разобрать подходы к оценке и запуску проектов. Возможно, их будет ждать очень неприятный сюрприз. А именно, что они вместо реальных оценок и попыток вписаться в эти оценки ( с дальнейшими разборками, почему не вышло и как сделать, чтобы вышло) практикуют wishful thinking с последующими "пускай в следующий раз повезет".
Но этого, конечно, не произойдет пока компания будет расти. Вот когда вы попадете в кризис, возможно и мотивации на изменение появится.
chilicoder
11.07.2023 07:11+1Вы знаете, перечитал ваш пост и не нашел там особой драматичности как в первый раз. Ну да, только с опытом приходит понимание того, что с первого раза конфетка не получится. А молодым инженерам зачастую кажется, что они сразу сделают революционную суперсистему с кучей инноваций.
Понимание приходит с возрастом. Поэтому важно иметь в коллективе опытных инженеров, присматривающих за молодежью. За этим балансом необходимо следить, но это уже тема для другого поста.
sergey_privacy
11.07.2023 07:11Любая работа должна оцениваться нормальным специалистом, должны накидываться часы минимум 10% на форс-мажоры. Если много логики, много непонятных ранее моментов, то запасных часов может оказаться как 50%, так и 100. Сроки определяет не бизнес, а исполнитель. Если исполнитель не попадает в сроки, устраивающие бизнес - увеличивайте штат разрабов или двигайте дедлайны вправо, иначе выйдет говно, которое придется переделывать, что будет дороже.
Если что то можно сделать костылем или долго, то делаем долго. Любой костыль рано или поздно становится стоп-фактором, который потребует пристрелить проект. Это закон. Если сейчас костыль родили за 5 часов вместо нормальной реализации за 40ч, то потом выкинете в помойку тысячи часов и начнете закапывать еще тысячи на новую реализацию. Любого сотрудника, который предлагает костылить или который сделал костыль, надо привязывать к лавке и каждый сотрудник компании должен подойти и высечь его розгами. Чтобы навсегда запомнил, насколько говнокод - это больно. У него должен появиться рефлекс: костыль = очень много боли. А тимлида, который пропускает костыли в работу - гнать ссаными тряпками. В любой работе, в любой среде костыли потом несут кровь, боль, хаос.
aldekotan
11.07.2023 07:11+1Часто слышу такую точку зрения, что если бизнес, через разработчиков, не будет применять все возможные способы обойти конкурентов, включая костыли и "говнокод" - он может не успеть занять место, и потом уже никому качественный продукт нужен не будет, потому что костыльный - сделали раньше и успели доделать "по ходу". Не знаю, насколько это разнится с реальностью
0x131315
11.07.2023 07:11Все эти оценки и грейды быстро разбиваются о суровую реальность и отваливаются. По факту все зависит от опыта. Есть опыт - просто работаешь, нет опыта - работаешь долго и проблемно.
Работы всегда много, поэтому какие-бы оценки не были, человек в любом случае двигается вперед. Терять людей не выгодно, поэтому независимо от оценок, грейды и зарплаты растут, иначе человек быстро уйдет к более заинтересованным конкурентам, где ему голову морочить не будут. Итого, по тому что вижу на практике, оценки и грейды не работают, это просто безусловные ачивки, как диплом в туалете.
Первые 2-3 года людей пытались оценивать, потом просто стали двигать по грейдам без условий, из-за бесполезности сего занятия. Осталось только минимальное ревъю/отзывы, для новичков, для отсева совсем тяжелых случаев. В остальном если человек хотя бы средне тянет свою работу - ему уже присмотр не нужен, гениальности и каких-то достижений никто не требует, достаточно просто работу работать.
В реальности все упирается в основном в процессы: независимо от того насколько человек хорош, он мало что может сделать с недостаточно отлаженными процессами, это даже не его уровень, и не его задача. А процессы почти везде налажены недостаточно - хаос есть всегда и везде.
Устраиваются встречи, обо всем договариваются, все решается, а потом... просто тишина на несколько месяцев. Сомнения, метания, какие-то несогласованные изменения. И внезапно наступает сильная активность: срочно в работу, по новому ТЗ, сделать нужно вчера, боссам уже доложили что все готово, у менеджмента попа горит. Знакомо? Первые пару лет люди пытаются бороться с этим, проактивничают, потом оставляют попытки: это бизнес-машина, так она работает, изменить это сложно. Все быстро меняется: то что вчера было нужно срочно, будучи реализованным в спешке и дорогой ценой уже завтра, внезапно становится не важным, и про реализацию забывают еще на пару недель, а потом опять внезапно прибегают с горящей попой. Абсолютно не согласованный тяни-толкай. Ну и как тут оценивать что-то? Процесс в целом неэффективен, от начала и до конца, на всех уровнях, но причина то не в людях, а в руководстве, которое нередко перекладывает вину на людей через такие оценки - забавное явление. На такие обвинения даже ответить нечего, только фейспалм пробить остается, и поискать компанию с более адекватным руководством.
gandjustas
11.07.2023 07:11Два раза не получилось, на третий раз сделали нормально. Хорошо бы как-то заранее научиться делать с первого раза хотя бы приемлемо.
nikolz
11.07.2023 07:11Читая статью вспоминаешь пословицу: "Не в свои сани не садись, не за свое дело не берись"
Alex-ok
Ничего не понял, но очень интересно!
skyblade
Что-то на менеджерском, попробуй через переводчик прогнать или через chatGPT