В этой статье я расскажу о балансе между техническим совершенством и скоростью разработки, и о том, почему профессионализм — это не только технические навыки.
Идея написания этой статьи у меня возникла после публикации статьи «Путь инженера» — кажется, будет полезным развить эту тему и поговорить более детально обо всём, что пересекается с основной мыслью.
Вступление
Программирование — это искусство создания систем, которые живут и развиваются, взаимодействуя не только между собой, но и с людьми. Программирование — это искусство превращать бизнес-идеи в рабочие, приносящие пользу и прибыль решения. Программист — это мост между миром идей и миром решений. Но как сохранить баланс, когда бизнес требует скорости, а инженерное сердце жаждет совершенства?
Личный опыт
В нашей компании было несколько проектов, где инженеры потратили много времени на разработку архитектуры и написания кода ещё до того, когда это станет востребованным и начнёт приносить прибыль:
- Ещё когда мы работали по Kanban, один из инженеров взялся разрабатывать сервис по канонам Domain-Driven Design без понимания этой методологии — в результате сервис взял на себя слишком много ответственности, а реализация затянулась и пошла «мимо». Когда требования изменились, переработать систему оказалось дороже, чем написать её с нуля. Если бы этот сервис он делал итеративно, делая каждый шаг в рамках одного спринта, то первая его версия смогла бы показать все недостатки, которые можно было бы исправить в последующих шагах.
- Уже после перехода на Scrum один из инженеров взялся разрабатывать интеграцию с платёжным провайдером по всем законам идеального кода: спроектировал архитектуру максимально абстрактной и универсальной, написал чистый код и покрыл тестами бОльшую его часть, написал документацию — всё это привело к удорожанию стоимости разработки в несколько раз. Однако, продукт не «выстрелил» и не окупил вложений. Если бы эту интеграцию он делал итеративно, то первая его версия смогла бы выполнять необходимый минимум, но была бы реализована за более короткий срок, а в этот же спринте он смог бы доставить другие важные ценности для других продуктов.
Главные выводы, который можно сделать из этих примеров:
- Не нужно применять теоретические знания новых для себя технологий или методологий без практического опыта в ключевых сервисах большой системы, даже если кажется, что ты их понимаешь на 100%.
- Нужно работать итеративно и в первой итерации делать наиболее минимальную версию, применяя правило 80/20 (фокус на 20% функционала, которые принесут 80% пользы, а не на краевых случаях, которые могут и не случится).
Инженер должен понимать бизнес-контекст и задаваться вопросом «Какое решение принесёт максимум ценности здесь и сейчас?», а не вопросом «Как написать идеальный код?». Инженер должен писать код так, чтобы изменения не становились катастрофой, и помнить, что даже самый элегантный код может стать бесполезным, если он не решает реальных проблем или продукт, для которого он писался, окажется не востребованным.
Даже Робер Мартин в своих книгах, в которых пишет про «Чистую архитектуру» и «Чистый код» не раз напоминает о том, что код существует не для того, чтобы восхищать коллег, а для того, чтобы служить бизнесу — кроме «идеальности» существуют и другие критерии оценки качества работы инженера: прагматизм, скорость доставки ценности бизнесу, способность находить баланс между идеальными решениями и реальными ограничениями проекта.
Рекомендации
Бизнес-ориентированность:
- Изучайте ключевые бизнес-метрики продукта;
- Участвуйте в обсуждении продуктовых гипотез и MVP;
- Оценивайте влияние технических решений на бизнес-показатели;
- Устанавливайте границы между «достаточно хорошо» и «идеально» для каждой задачи;
- Проводите регулярные аудиты технических решений с точки зрения их ROI для бизнеса.
Понимание бизнеса помогает принимать решения, которые приносят реальную ценность, а не просто соответствуют техническим стандартам.
Итеративная разработка:
- Начинайте с минимально жизнеспособного продукта (MVP);
- Планируйте доработки в следующих итерациях на основе обратной связи;
- Выделяйте время в спринтах на управление техническим долгом;
- Используйте A/B-тестирование для проверки гипотез перед масштабированием функционала.
Итеративность минимизирует риски за счёт постепенного внедрения и проверки гипотез.
Командное взаимодействие:
- Развивайте навыки общения с нетехническими специалистами;
- Документируйте ключевые решения и их обоснование;
- Участвуйте в кросс-функциональных обсуждениях;
- Проводите регулярные код-ревью для обмена опытом;
- Внедрите «ритуалы» для синхронизации: ежедневные стендапы, ретроспективы.
Эффективная команда функционирует как экосистема с непрерывной обратной связью и согласованными целями.
Личностное развитие:
- Развивайте soft skills: эмоциональный интеллект, тайм-менеджмент;
- Учитесь говорить «нет» необоснованным требованиям;
- Признавайте и анализируйте ошибки;
- Фокусируйтесь на задачах с максимальной отдачей.
Личностный рост требует баланса между стремлением к идеалу и принятием реалий.
Профессиональное развитие:
- Следите за трендами;
- Регулярно обновляйте технические навыки;
- Участвуйте в формировании технических стандартов команды;
- Учитесь «продавать» технические решения бизнесу.
Профессионализм заключается в постоянной адаптации к изменениям и развитии навыков.
Дополнительные рекомендации:
- Самая главная рекомендация, которую я могу дать: если вы четко понимаете, что нужно сделать и как это должно работать, то не стесняйтесь использовать Google Driven Development, Stack Overflow Driven Development, Habr Driven Development и AI Driven Development. Нет ничего плохого в том, что кто-то или что-то помогает вам советом или направляет в нужную сторону. Более того, автоматизация некоторых процессов написания кода — это абсолютно нормальное и даже рекомендуемое решение.
- Ещё одна, но не менее важная рекомендация, которую я могу дать: учитесь получать удовольствие не столько от самого процесса написания кода, сколько от конечного результата, подтвержденного бизнес-метриками.
Итог
Хороший код — это не тот, который следует всем принципам, а тот, который понятен, поддерживаем и делает то, что от него ждут.
Цель написание хорошего кода — не идеальный код сам по себе, а работающий продукт, который решает задачи пользователей и бизнеса.
Баланс — это искусство принимать осознанные решения. Баланс достигается тогда, когда инженер перестаёт делить мир на «технарей» и «гуманитариев» и начинает мыслить, как соавтор продукта, а профессионализм инженера проявляется в умении отличать «надо» от «можно». Да, технический долг неизбежен, но он должен быть осознанным шагом, а не следствием хаоса. Да, скорость важна, но она не оправдывает код, который невозможно поддерживать.
Инженер должен быть не просто исполнителем, а партнером бизнеса, который может предложить наиболее короткий путь достижения целей. Важно помнить, что идеальный код часто становится препятствием на пути к успеху продукта, если он мешает своевременному выходу на рынок или тестированию важных гипотез.
Срединный путь — это путь гармонии, избегающий крайностей @ Будда
P.S. Как вы определяете, когда стоит остановиться в стремлении к идеальному коду и переключиться на доставку рабочего решения? Можете привести пример из вашего опыта? — Напишите об этом в комментариях.