Правильно или быстро?

Срочная задача

Допустим, прилетает срочная задача от “клиента”. Обсудили, нужно срочно сделать, тогда будет прибыль и будет все хорошо.

“Срочная задача” вклинивается в текущие задачи, другие “срочные задачи” откладываются, наполовину сделанные останавливаются.

Задача была поставлена сходу устно, конечно же без ТЗ, без проработки рисков, без продумывания тысячи условий.

Время не ждет, нужно клиенту делать сейчас.

Что получаем чаще всего в итоге:

• Текущие задачи приостановлены ради “срочной”, что не всегда дает возможность вернуться к текущим задачам позднее, из-за ограничений накладываемой “срочной задачей”.
• Задача сделанная на “костылях” поначалу работает. Через какой-то период времени, она перестает работать и тогда начинается веселье. “Костыль” не дает возможность внедрить по настоящему продуманные задачи.

Получаем проблему на которую нужно смотреть с разных сторон.

Со стороны клиента

Важно понимать, что цель любого бизнеса получение прибыли, а не эти ваши красивости, правильные решения, подбор правильных паттернов проектирования.

С точки зрения клиента, разработка сервиса это просто расходы, чтобы потом увеличить прибыль, и не чего более.

Клиент может ничего не понимать в IT, а исходить из принципов расходов оптимального минимума.

Что имеется ввиду.

Например, клиенту нужен интернет магазин. Вроде все работает, но выясняется, что хостинг, на котором размещен интернет магазин крайне нестабилен, но он же работает, ответит клиент.

То есть здесь и сейчас он работает, а потом может не работать.

Далее клиент думает, какова вероятность наступления события отказа оборудования в работе хостинга. Она мала, но все же есть. К тому же вкладывать деньги в какую-то гипотетическую проблему в будущем нет смысла.

Допустим неприятное событие произошло, клиент потерял данные и своих клиентов, следовательно, свою прибыль, из-за того, что не сменил хостинг и не выделил деньги, когда это было нужно.

Но если все-таки деньги на новый хостинг были выделены, но по какой-то причине программист допустил оплошность, и все равно клиент потерял прибыль, тогда будут сделаны “другие выводы”.

Здесь однозначного вывода нет.

Со стороны программиста

Программист смотрит с технической стороны вопроса.

По сути программисту важно получить задачу, выполнить ее, получить деньги от клиента, все остальные организационные вещи слабо волнуют.

Но, любой клиент заинтересован в качественном выполнении задачи и за работу, сделанную на “скорую руку”, платить не готов.

Поэтому, главное тут сделать свою работу хорошо, чтобы не было вопросов после.

Например, проект доставшийся программисту, может быть откровенно “плохим”, чтобы быстро выполнить задачу заказчика.

Что это может быть:

• Проект не подготовлен к старту. Скачал код, нет банальной инструкции как его запустить. Разбирайся целый день, как там его развернуть локально.
• Нет инфрастуктуры для запуска. Можно отнести и к первому пункту, проект банально не в docker. Уже сложно его запустить. Снова полдня пытаешься его “докеризировать”.
• В коде нет комментариев сложных моментов.
• Не используется git. Даже не буду писать ничего.
• Велосипеды в коде. Зачем писать все самому, если есть проверенные решения. Мне это не понятно.

Отсюда затягивание сроков, непонимание как сделать, чтобы не сломать, то что уже работает, тестов же естественно нет.

Про хорошие практики как-нибудь напишу отдельную статью.

Итог

Какие выводы можно сделать:

• Бизнес расчитывает на быстрое получение прибыли и опережения конкурентов.
• Бесконечные проекты по срокам никакому не нужны.
• Если разработчик привык все делать правильно, но его подгоняют, он будет делать ошибки, из-за этого будет страдать качество его решения.
• Бизнесу не нужны четко выверенные решения, ему нужны решения которые работают прямо здесь и сейчас.

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

И последнее, что можно тут сказать “Все зависит от всего”.