Как быстро запускать проекты

Допустим, мы верстаем лендинги в компании. В понедельник нам пишет менеджер:

• — Привет! Дизайнер нарисовал лендинг с акцией, заверстай, пожалуйста. За сколько дней сделаешь?
• — Так, я сделаю за 4 дня, плюс день на исправление замечаний, так что через неделю запустим.
• — Эээ, чел, тут такое дело... Нам надо завтра запустить.
• — (начинается ситуация)

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

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

Менеджер мыслит запуском продукта, а программист — удобством разработки и поддержкой написанного кода. Ребята говорят в разных плоскостях. Давайте разберем ситуацию и подумаем, что мы можем предложить, чтобы запуститься за день и не умереть.

Кучу лет назад Артемий Лебедев сформулировал метод прогрессивного джипега, который гласит, что «в любую секунду любой проект готов на 100%, хотя проработанность может быть и на 4%». Главный вопрос: как сделать лендинг на 100%, проработав его на 4%.

Что, если вместо верстки добавить на сайт картинку с макетом? Ну вот просто <img src="/images/maket.jpg" />. Проект будет запущен, но не проработан. Конечно, любому уважающему себя фронтендеру станет плохо:

• — А что, если пользователь захочет скопировать текст?
• — А что, если медленный интернет? Чел будет ждать картинку всю жизнь!
• — Да о чем мы вообще говорим, так никто не делает, это кощунство, вы чего!

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

Поэтому первое, что делаем — спрашиваем у менеджера, откуда такие сроки, и зачем вообще мы это делаем.

Ответ на вопрос «зачем это надо» даст вам понимание до какой степени всратости фантазировать.

А ответ на вопрос «откуда сроки» нужен для мотивации и приоритетов. У нас всегда куча дел, и мы должны четко понимать, почему мы делаем что-то рабочее прямо сейчас, вместо того, чтобы смотреть сериал.

Мы спросили менеджера «зачем» и выяснили, что это информационный лендинг с акцией, который будут рекламировать для офисных сотрудников. Бизнес хочет понять, интересна ли такая акция людям, и стоит ли запускать производство.

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

Объясняем решение менеджеру и если он ок, то иди наливай, а я пока запущу проект.

Если менеджеру не ок, то разговариваем дальше:

• — А почему нельзя картинкой?
• — Нельзя по двум причинам: во-первых, у нас во втором блоке дизайнер хочет анимировать кубик; во-вторых, в конце страницы есть форма с заявкой — с картинки форму не заполнить.
• — А что случится, если этого не будет на сайте?
• — Ну, если формы не будет, то мы не сможем собрать заказы и понять, кому интересна акция. А анимация кубика для красоты, чтобы нескучно было листать страницу.
• — Без формы нельзя, конечно, надо делать. С анимацией кубика спорно, он же не решает задачу, а делать долго. Давай забьем на него в первой версии? Потом доделаю.
• — Ну ладно, давай. Форму-то как будем делать?

Короче, алгоритм такой:

1. Предложить решение с уменьшением проработки.
2. Если менеджер ок, идем работать.
3. Если не ок, то спросить почему. В итоге получаем список аргументов от менеджера.
4. Обсудить с менеджером каждый аргумент: делать или забить. Если без этого аргумента не решается задача продукта, то делаем, иначе — забиваем. Конечно, сделать хочется все, но важно отталкиваться именно от решения задачи, если хотим запуск быстрее. В итоге получаем список того, что надо сделать.
5. Подумать над списком, придумать решения с уменьшением проработки, повторить цикл.

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

Теперь давайте тоже самое, но с формой сбора заявок. Сначала определяемся, до какого предела можно фантазировать с проработкой:

• — Готов ли бекенд?
• — Если бекенда нет, то где хранить заявки?
• — Есть ли похожие формы на нашем сайте?

В общем, собираем инфу, зачем это нужно, а дальше решения пойдут сами:

• — Бекенда нет, отстой. Надо самому писать, я к завтра не успею, тем более, что похожих решений нет.
• — Слушай, если данные необязательно хранить у нас, то может сделаем гугл форму и вставим на сайт?
• — Кстати, а как мы общаемся с клиентами? Хм, через телеграм... Ёмаё, так давай я ссылку на телеграм бахну!

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

Конечно, есть опасность: при таком подходе легко скатиться в говно. Особенно, если принимаешь такие решения в одиночку без бизнеса.

Представьте, если бы Яндекс запустил свой Google Docs, но по факту вместо яндексового редактора запускался бы тот же гугл, только через айфрейм. Задача, вроде, решается, пользователь создает доку на сайте Яндекса, разработчик быстрее запустил продукт, но загубил репутацию команды.

На самом деле тут задача не решена, потому что «не похерить репутацию запуском» — тоже задача, которую надо учитывать при уменьшении проработки. Хороший менеджер знает эти задачи, поэтому надо с ним советоваться и держать в курсе своих решений.

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

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