"Мы довольны своей работой МАКСИМАЛЬНО, но, к сожалению, наша работа не дала результат" (с)
- каждый раз хихикаю с этого видео (ютуб, вк), и каждый же раз где-то на заднем плане возникает мысль о важности результатов, а не просто упорной работы. Как пелось у Linkin Park - "I tried so hard and got so far But in the end, it doesn't even matter". Ладно, хватит цитат, тем более, что песня "In the End" была совсем не об этом.
Фокус на конечном результате работы - амбициозном, видимом, классном - это та самая штука, которая заставляет мыслить более остро. Когда ты сфокусирован получить результат в условиях ограниченных ресурсов, ты отбрасываешь менее важное, ты бритвой Оккама отрезаешь лишнее, чтобы осталось самое главное. У этого подхода тоже есть оборотная сторона, но кто будет спорить с тем, что более крут тот менеджер, у которого более значимые результаты?
Не могу сказать, что у меня с этим нет проблем. Именно поэтому недавно крепко задумался о фокусе на результатах и решил поделиться парой мыслей тут.
1/ Лучше показывать, чем рассказывать
Можно рассказывать разные концепции, обсуждать уровни реализации, но если есть что-то, что можно показать - код, дизайн, прототип - это точно ускорит получение обратной связи и сделает ее более релеватной. Кроме того такие штуки лучше запоминаются людям - в момент перфоманс-ревью коллега Вася вспомнит скорее ваш первый прототип системы авторизации и то, как это продвинуло диалог, чем десятое обсуждение процесса резолвинга идентификаторов в человекочитаемые строки. Отчасти это связано с тем, что людям проще сказать, что "не так", чем "как именно надо".
2/ На старте любой движухи подумать, что можно отдать в качестве MVP прям завтра.
Не, ну не прям завтра, а на этой неделе, например. Тут MVP я использую в значении "минимальный значимый результат" - что-то такое, что уже будет ценно для поставленной задачи, хоть и решает ее не полностью. Нужно провести исследование - можно по быстрому отдать первую версию плана. Нужно написать RFC - аппрувнуть структуру и основные тезисы (хотя с обсуждением сырого RFC я бы был осторожен). Думаю, принцип понятен. Эта мысль засияла для меня чуть ярче, когда я пилил свой pet-проект - когда ты своими собственными деньгами отвечаешь за разработку, то находить быстрые решения становится полегче. Например, можно не корпеть над текстами транзакционных писем, а просто сделать хоть какие-то уже транзакционные письма, а текст сделать чуть позже.
3/ "Better done than мать его perfect”
Другими словами лучше сделать НОРМ и заданные сроки, чем полировать до совершенства непойми сколько. Ох, сколько раз я себе говорил это - вот еще одно интервью проведу и все будет совсем понятно, вот еще тут формулировки на слайде дополирую и все будет как надо. И ведь все равно не наступает тот счастливый момент, когда все прям супер-пупер! Все равно всегда находится еще одна мелочь, которую надо поправить. Именно поэтому эта фраза так засела в голове - она немного возвращает перфекциониста с небес на землю.