Привет, Хабр! (И тебе, случайный читатель, который открыл эту статью в перерыве между двадцатой правкой того, что ты ещё месяц назад гордо назвал финальной версией).
Сегодня давайте попробуем без кода и без нытья, пофилософствуем на тему:
«В какой момент продукт вообще можно считать законченным?»
Я задумался об этом относительно недавно (пару месяцев назад) на мероприятии (о котором у меня уже выходила статья). Ходишь ты такой по фестивалю, смотришь на продукты Яндекса и ловишь себя на мысли: Вот этот небольшой сервис (я не буду его называть, чтобы вы сами попробовали угадать, хотя сюда подходит реально много продуктов...) и он уже почти 20 лет существует, а над его доработками и улучшениями каждый день работают десятки, а то и сотни разрабов, аналитиков, менеджеров и других.
И тут встаёт нормальный на первый взгляд вопрос: когда можно честно сказать «всё, хватит, теперь идеально»?. Когда уже пора остановиться с разработкой? Да, это чисто философия, но мысль, как мне кажется, интересная…
Сразу спойлер для ленивых: ответа у меня нет. Зато есть ощущение, что «готового» продукта в природе вообще не существует — есть только продукт, который просто на время перестали трогать. И мне правда интересно, что вы скажете в комментариях на это. Может, рассудите. Может, докажете обратное. Может, согласитесь. А может, и поспорите между собой))) почему бы и нет…
Короче к делу...
Глава 0. Иллюзия финишной черты
Когда ты начинаешь делать что‑то своё: Pet‑проект, скрипт, сервис, в голове всегда есть чёткая картина «Доделаю это и всё… заживём… релиз…». Такая красивая и идеальная финишная ленточка. Думаю, у каждого так… По крайней мере у меня так)) Но проблема только в том, что ленточка‑то эта почему‑то постоянно куда‑то убегает. Ты добегаешь до неё, а она ещё дальше, чем была. Доделал парсер — надо бы выгрузку в Excel добавить. Сделал выгрузку — а давай график нарисуем. Сделал график — а чё он не по регионам? А цель казалась такой простой.
И вот ты уже полгода сидишь и полируешь то, чем должен был по сути пользоваться. Но идея вечного допила взяла над тобою верх.
Знакомо? Мне ДА.
У меня был кейс из недавних. Задача: сделать обработку банковских платёжек. Сделал в короткие сроки. Не спал, не с... но сделал... Заказчик благодарен. РП благодарен. Но мой глаз продолжает дёргаться, но уже не на цель разработать быстро в короткие сроки, а на то, что обработка 10 000 платёжек занимает 30 минут, а это долго, очень долго. Короче я начал оптимизировать, потом оптимизировал оптимизированное, а потом оптимизировал оптимизированное которое уже было оптимизировано и так несколько недель. Никто об этом не просил, просто навязчивая идея, которая не давала спать.
…Да, конечно, в результате обработка с 30-ти минут сократилась до 5-ти минут (Кстати на помощь мне пришла O‑нотация которая используется в анализе алгоритмов. Не думал, что данные знания из книги «Грокаем алгоритмы» пригодятся. Но привет Яндекс с алгоритмическими интервью) … Но это не нужно было никому… Ни заказчику… Ни РП… Нужно было чтобы разработка была доступна пользователю как можно скорее, а моя оптимизация нет. Пользователь бы потерпел. Но я так не мог.
И здесь я сразу смею предположить, что всё это, вытекает из‑за нашей любви к себе, любви к своему коду (вот это поворот). Мы просто творцы, а наш код это искусство (к сожалению или к счастью). Да. Для нас… Возможно только для нас… Но искусство. И нам нужно как‑то побеждать в себе этого художника — загонять его в рамки. Вы можете сказать — так нельзя, но как бы этого ни хотелось так надо. Идеальный продукт или нет решаем ведь не мы, а решает наш заказчик.
Лично я каждому своему новому проекту сначала притираюсь, придираюсь, а потом признаюсь в любви, но не избежно придётся с ним расстаться, так как в переди новые «любимые»...
Но бывает и другая сторона…
Глава 1. Ещё одна маленькая кнопочка
Есть отдельный жанр вечного допила — когда допиливаешь не ты, а тебя.
Заказчик или всеми любимая Марья Петровна приходит с фразой (которая всем нам знакома): «Тут надо совсем чуть‑чуть переделать. Буквально одну кнопочку добавить. Сделаете?» И ты знаешь, чем это обычно заканчивается:
Кнопка должна сохранять данные. Но сохранять не просто так, а с проверкой. Проверка требует новое поле «Причина нажатия». Причина: таблица БД, которой нет. Таблица, естественно, ломает старую выдачу, потому что теперь там должен быть новый фильтр. Фильтр требует переписать SQL‑запрос.
И вот сидишь ты такой, через три дня, с новой архитектурой, миграцией на 15 таблиц в БД и переписанным бэкендом, смотришь на эту кнопку и думаешь: «Ну, буквально же одна кнопка…».
И мы видем, то что продукт был готов, но только до тех пор, пока кто‑то не посчитал, что он недостаточно готов.
А был ли вообще когда‑то готов? Или это просто пауза между хотелками? (Да, хоть вводить эту мысль в учебники по философии. Но поразмышлять то хочется)
Глава 2. И тут я вспомнил про 1С
Не могу пройти мимо Великого и ужасного — Мира 1С, похоже, самый чистый пример вечного допила. Там продукт вообще не задумывают по умолчанию как что‑то законченное. Типовая конфигурация живёт сама по себе, никого не трогает, а потом её обновляют, потом на неё навешивают доработки, потом эти доработки начинают конфликтовать с обновлениями, а обновления в ответ рождают новые доработки... И так по кругу...
В этом и есть смысл 1С. Здесь точка «готово» не предусмотрена архитектурой.
Но всё это вообще не только про 1С. Я его отметил, потому что здесь допил доведён до абсолюта. А так этим болеет абсолютно любой живой продукт, который кому‑то хоть каплю нужен и который кто‑то любит (возможно именно ты). Мёртвые проекты не дорабатываются, запомните эту мысль…
И тут снова неприятный вопрос: вечный допил — это скорее знак того, что продукт живой? Или всё‑таки мы просто не умеем вовремя сказать себе «хватит»?
Глава 3. Так, где же выключатель?
Я пожалуй выделю здесь три ка мне кажется подходящих пути, хотя их на самом деле больше (можете предложить свои в комментах), и все три по своему правильные и не правильные.
Есть лагерь «Работает — не трогай». Здесь продукт готов только в тот момент, когда решает задачу. Всё. Кривовато? Плевать. Задача закрыта, иду и делаю следующую. Технический долг? Это проблема уже будущего тебя. А он мужик я думаю крепкий, справится с этим как‑то…
Лагерь «Доведи до ума». Готово наступает тогда, когда не стыдно. Код чистый, тесты зелёные, архитектура не сыпется от одного взгляда… Но проблема здесь следующая: до этого состояния продукт не доходит примерно никогда, потому что «идеально» это всегда относительная и вечно движущаяся цель.
И последний заключительный лагерь «Отпусти и забудь» — авторское название)) (Или как поётся в мультике. Отпусти и забудь, что прошло — уже не вернуть. Отпусти и забудь, новый день укажет путь. Как же в тему…). Как будто самая правильная стратегия. Идея простая: продукт готов, когда дальнейшие улучшения приносят меньше пользы, чем новый проект, на который ты потратишь то же время. То есть в какой‑то момент полировать старое становится прокрастинацией с чувством собственной важности. И это нужно обнаружить и победить в себе.
Я повторюсь: разработчик всё‑таки творец и каждый творец любит своё детище и желает для него только самое лучшее… (Хороший садик, хорошую школу… ой не то…) Быструю работоспособность, красивый интерфейс, большое количество фич и тд…
Ещё один кейс от меня. Я на текущем проекте безумно влюбился в разрабатываемый продукт. Но со временем и несколько бессонных ночей решил, что стоит всё‑таки чуточку проще относиться к нему и не уходить в дебри перфекционизма и доработки до идеала, особенно на этапе MVP (так как больно всё таки слышать, «Эта функция не очень! Давай убирай.»). Теперь я выписываю свои хотелки в блокнотик и если у меня появится время я посмотрю на него и то что мне покажется супер‑полезным из всего этого, то и сделаю. Долго грузится форма из‑за получения данных (для меня это от 3-х секунд), пишу в блокнот, потом через несколько дней смотрю и думаю Норм? Или всё таки стрём?, Нет, значит пусть лежит дальше.
Да, да… Конечно, мы разработчики люди не то, чтобы свободные)). И задачи бывают разные, полезные и нет, любимые и нет. Поэтому нам нужно стараться влиять и фильтровать хотелки будь то наши, будь то заказчика. Иначе продукт свернёт куда‑то не туда и сотни трудодней будут впустую.
На вопрос: как отличить «продукт ещё требует работы» от «я просто боюсь его отпустить и начать новое»? …Возможно стоит начать ввести метрики на подобии Definition of Done (советую ознакомиться кто не знаком) или придумать что‑то своё…
Вердикт
Мне кажется, продукт готов в тот момент, когда следующая доработка уже не оправдывает те ресурсы, которые на неё уйдут. После этого любые правки — это уже не про развитие, а скорее про перфекционизм, либо просто способ оттянуть запуск нового проекта.
И вообще, вопрос «продукт готов?» мне кажется не самым точным. Давайте лучше спросим по‑другому:
Нужна ли эта конкретная доработка кому‑нибудь, кроме моей тревоги или тревоги менеджера?
Но, если честно, это всего лишь моя гипотеза дилетанта, который скачет между технологиями и проектами и нигде не задержался настолько, чтобы пилить один продукт десять лет подряд...
Пишите комментарии свои мысли на эту тему. Мне правда интересно, есть ли среди вас те, кто хоть раз сказал продукту: «ты готов» и не соврал соответственно.
P.S Понравилась статья? Ставь плюсик и подписывайся, у меня не только такая философия, как эта)) А ещё и аналитика IT рынка, обзор и разбор тех продуктов которые все обходят стороной (а возможно зря) и разные мои проекты. Можете поддержать меня (при большом желании), нажав на кнопочку «Задонатить», ну это прям для сильно желающих.
