С какой самой сложной задачей столкнулся в рабочем проекте

Самая сложная задача: преодоление недостижимого

Для меня самая сложная задача была не техническая, а организационная и психологическая.

Контекст: спасение проекта на краю отмены

Ситуация:

• Проект работал 18 месяцев, потратили $500K
• Deadline в 2 недели
• Функционал был готов на 40%
• Тестирование выявило 500+ критических багов
• Team морально сломана (привык к неудачам)
• Начальство рассчитывалось на отмену проекта

Моя роль: я был назначен tech lead для "salvage operation".

Сложность 1: Техническая

Проблемы: Одновременная работа 20 разработчиков на legacy коде:

• Merge конфликты каждый день
• Каждый день вносились новые баги
• Test coverage: 5%

Как я решал:

1. Остановить хаос (день 1)

   • Заморозил новый функционал
   • Давал только bug fix PR'ы
   • Ввел strict code review

2. Быстро покрыть тестами (дни 2-5)

   // Вместо писать unit тесты к legacy коду (долго)
   // Написал integration тесты (быстрее)
   @Test
   public void importantScenarioWorks() {
       // E2E тест: пользователь -> backend -> БД -> response
       // Ловит большинство багов, пишется быстро
   }
   

3. Распарал работу (дни 3-10)

   • 10 разработчиков: bug fixes (по приоритету)
   • 5 разработчиков: тестирование (smoke tests)
   • 3 разработчика: рефакторинг (критичные части)
   • 2 разработчика: инфраструктура (CI/CD)

Сложность 2: Организационная

Проблема: team потеряла веру в проект.

Как я решал:

1. Четко сказал что-то правду

   • "Проект был в беде, но мы МОЖЕМ это исправить"
   • "Не все успеем в совершенстве, но 80/20 даст нам рабочий product"
   • "Вы классные разработчики, просто условия были сложные"

2. Дал победы (quick wins)

   • День 1: уменьшили crítico bugs с 500 до 300
   • День 2: покрыли тестами основные сценарии
   • День 3: впервые прошло интеграционное тестирование
   • Люди увидели: "О, мы МОЖЕМ!"

3. Защитил team

   • Начальство хотело добавить людей
   • Я сказал нет: "Больше людей = больше хаоса"
   • Вместо этого четкая структура и приоритеты

Сложность 3: Психологическая (самая сложная)

Проблемма: я сам был под огромным стрессом.

Как я преодолевал:

1. Принял реальность

   • Невозможно всё сделать идеально
   • Нужно выбирать: качество vs время
   • Выбрал: рабочий + 80% quality

2. Нашел смысл в каждом дне

   • День 1: заморозили хаос
   • День 2: появился план
   • День 3: первые победы
   • День 7: видна финиша

3. Спал 5 часов, но делал зарядку

   • Здоровье важнее дедлайна
   • 20 мин упражнений давали мне энергию на 4 часа

Результат

На 10-й день:

• Критических багов: с 500 до 20
• Test coverage: с 5% до 65%
• Team: с "мы проиграли" на "у нас есть шанс"

На 14-й день: проект выпустили.

В production:

• 95% функционала работал
• 50 известных багов (minor)
• Пользователи были довольны (expectations были низкие)
• Начальство удивлено: "Вы сделали невозможное"

Через 3 месяца:

• Исправили оставшиеся баги
• Рефакторили и улучшали
• Проект стал успешным

Почему это была самой сложной

Не потому что сложная техническая задача (я решал сложнее).

А потому что нужно было:

1. Верить в невозможное
2. Оставаться спокойным под давлением
3. Вести людей, которые сломаны
4. Принимать неидеальные решения
5. Жертвовать качеством ради выживания

Это учило меня больше, чем все архитектурные задачи вместе.

Главный вывод

Самая сложная задача в разработке — не код. Это люди и принятие решений под неопределенностью.

Тех. знаний достаточно. Но мудрость приходит когда:

• Знаешь когда сказать "нет"
• Знаешь когда пожертвовать совершенством ради результата
• Знаешь как вести людей в сложные времена

Это опыт, который не найдешь ни в какой документации.