Я хотел, чтобы все сломалось
👁 559↗ 10💬 3
6 лет назад я работал бекенд-разработчиком и всегда был настроен делать все "правильно". Выстраивал архитектуру так, чтобы в будущем не было проблем. Продумывал досконально, следил, чтобы ничего не выстрелило в ногу.
Минус такого подхода - я срывал сроки.
В какой-то момент наши отделы объединили, и я начал работать с Олегом - моей полной противоположностью. Он делал все быстро, в лоб, не думая о последствиях.
История, которая изменила мое мышление:
Застрял я на проекте, где нужно было тянуть данные из чужой базы. Создал специальный сервис-прослойку - ведь нельзя же напрямую подключаться к базе другого проекта! Изоляция данных, все дела.
Сорвал срок на спринт. Подключили Олега.
Он просто взял и подключился напрямую к той базе. За день.
Бизнес был в восторге - задача решена быстро, работает отлично! А я объяснял всем: это неправильно, код станет запутанным и зависимым. Если в том проекте изменят структуру базы - у нас все сломается.
Говорил, что последствия будут ужасными. Меня не слушали - решение же работает великолепно прямо сейчас.
Мое эго было задето.
К этому добавлялось чувство справедливости и ожидание: вот-вот что-то пойдет не так. Я ХОТЕЛ, чтобы что-то пошло не так. Хотел, чтобы наконец-то меня услышали и сказали: "Да, Кирилл, ты был прав". У меня прям на языке вертелась фраза, я ждал свою минуту, когда скажу: "Ну я же говорил!"
Спустя год... ничего не произошло.
Проект как работал, так и работает. Я по-прежнему настаивал на "правильных" решениях, но побеждали быстрые.
И тут я начал думать:
Может, я все это время решал проблемы, которых не существует? Защищался от будущего, которое никогда не наступит?
Сколько фич мы не выпустили, пока я строил идеальную архитектуру? Сколько денег потерял бизнес, пока я боролся с воображаемыми драконами?
Олег делал костыли, но бизнес рос. Я делал "правильно", но срывал дедлайны.
Парадокс в том, что технический долг, о котором все говорят - он не всегда наступает. Иногда проект умирает раньше. Иногда его переписывают с нуля. Иногда тот самый костыль работает годами, и никто его не трогает.
Где граница между перфекционизмом и профессионализмом? Между качеством и оверинжинирингом?
Пишите в комментах свои мысли.
60/100
Telegram | YouTube | Запретграм
343
Комментарии · 3
- @shredder888Думаю вырвано из контекста, мое субъективное мнение. Задачи должны ставится исходя из логики бизнеса, и стратегических задач которые мы опускаем на отделы в вехи. И в случае если решение Олега решало стратегическую задачу оно было верное, но твоё решение должно было зафиксировано в бэклоге, как следующий этап с пометкой todo. Проблема думаю как чаще всего бывает в коммуникации, а не в том как пишется код или делаются решения по стадию проекта. Если бы у вас была открытая коммуникация и вы договорились что сейчас делаем так а потом обязательно нужно сделать правильно, когда например стратегическая задача выполнится и например "работа встанет на рельсы" и будет время для доработки. Что касается сабжа, опять же от себя, я бы наверное ночами не спал вне рабочее время делал параллельно это решение чтобы потом дать как улучшение. Также если мы говорим про качество и скорость, не всегда нужно и то и то, если ты работаешь сам на себя с ограниченным бюджетом. Но когда ты в интерпрайз компании, где есть и над Олегом и над тобой руководитель, то по сути нужно было от вас несколько мнений и уже ответственность нести будут они и ваша задача расслабится и получать удовольствие. Проекты умирают чаще из за недостатка финансирования или реже из за неверных гипотез не реализуемых, когда ожидания результатов от этих гипотез не совпадают с реальностью. И ваша работа на это не как не влияет ❤️
- @boysdontcrieЛично у меня так бывает, когда я опираюсь в решениях на «что-то», «кто-то», так сказал и «в гугле так делают» - не думая своей головой - не примеряя это здесь и сейчас на том с чем работаю я, а не тот чел из книжки или подкаста. Если вероятность реализации риска высокая (тут - изменение бд), то реалистично сделать предупреждающие действия (тут - прослойка). Если низкая - то и париться незачем. Провели оценку, выяснили: риски вероятные, реалистичные, урон - критический. Уточняем у бизнеса, что сроки сдвинутся, объясняем на пальцах. Ну в общем самое главное - оценка реалистичная в данном случае, более детально раскладывать каждое суждение и докапываться даже до того, что кажется очевидным. Типа включить критика для самого себя Применяю в работе это, теперь чаще усмехаюсь от своих же предложений борьбы с ветряными мельницами
- @hisukovЖиза!