Помню, когда-то давно, когда я еще сам и не нанимал, а всё больше (не) нанимали меня, я прочел статью Спольски про то, что же он ищет у кандидатов. Если выкинуть всё лишее, то останется лишь 2 корневых требования — “smart & getting things done”. И я сам уже довольно много лет пытаюсь нанимать, руководствуясь именно этими пунктами. Пункт “smart” у меня как-то никогда не вызывал вопросов — идиотов я не переношу практически органически. А вот с “getting thing done”, как я недавно понял, у меня переодически бывают проблемы. Я вижу отличного человека, который правильно думает, которому многое дано, но который при этом… никогда не добивается результата.

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

Один был спецом с отличным опытом и подготовкой, который четко представлял, как должен выглядеть конечный результат, но… был готов хоть что-то делать, только если вокруг всё было идеально.Идти и спорить с идиотами, объяснять им, что и зачем, собирать временные решения, минусы которых очевидны, но которые здесь и сейчас сделают лучше — нет, всё это было не для него. В какой-то момент я просто подошел к точке, когда практически не мог с ним разговаривать. Очередное “ну вот, я-то всё правильно делаю, а кругом идиоты” вызывало желание убить на месте.

Второй… второй был похож. Хорошо рассуждал, мог придумать, что, как и почему именно так делать, но… Не доводил до результата. Хронически. Болезненно. Срываясь в прекраснодушные мечтания там, где надо было сжать зубы и доделать. Перетерпеть и доделать, хотя бы для того, чтобы забыть про этот хвост. Ну что поделать, если человек быстро теряет интерес к задаче. Учился, читал книги, ездил по выставкам и конференциям, снова придумывал классные идеи, которые опять повисали недоделанными неопрятными долгостроями, которые гнили в таск-трекере. И потом, конечно, приходит просить денег, т.к. он много знает и правильно думает. Но вот только от этого “много и правильно” болезненно мало толку. И на очередной запрос “съездить на конференцию” или “давно не повышали”, как-то хочется ответить предельно невыдержанно.

Деградацию третьего я наблюдаю сейчас. Наблюдаю с болью и какой-то обреченностью. Хорошие задатки, хорошие знания, и опять планомерное убивание своего проекта и себя. Производство продукта “так себе” с красивыми академичными кусками процессов, которые при этом, похоже, используются проформы для. И, конечно же, кругом одни идиоты.

И у меня всё больше печальное ощущение, что просто быть умным, пусть и очень умным и знающим, недостаточно. И правильно говорить — нет, недостаточно. Надо правильно делать. Или неправильно. Но до конца, до результата. И пункт “кругом идиоты” уже как красная тряпка, как и пункт “дайте мне вот это, вот это и это всё, и вот тогда я начну работать”. Похоже, что “работать” — такое же качество, как и “умный”. Если оно есть, то человек будет работать, независимо ни от чего. Условия, деньги, подчиненные, начальство, окружение… просто будет что-то делать. Чтобы “из состояния ужас-ужас перейти в состояние очень плохо”. Правда, по опыту, следом этих людей находят и деньги, и условия, и подчиненные. Просто потому что их мало, и их как-то всем не хватает.

Я всегда считал, что хороший проджект, прежде всего, — человек, которому больше всех надо. Человек, которому не всё равно, который любит свой проект, готов пахать и долбить ради него, зажигать людей вокруг, показывать, объяснять, тащить проект к запуску на зубах, через “не могу”. Я любил очень многие свои проекты и, наверное, именно это помогало мне. И до сих пор люблю. И за многие я горд, а за многие мне очень больно, очень обидно смотреть, что с ними происходит, хоть и есть некоторая доля злорадства. Ну как же, не смогли без меня…

И, тем не менее, чем дольше я работаю в индустрии, тем меньше верю в страсть, в ощущение, и тем больше верю в цифры. Не в том банальном смысле, что “самое красивое в игре — это счет”… хотя нет, и в нём тоже. Просто, чем больше у меня опыта, тем меньше я готов ему верить, тем больше равновероятных вариантов я могу допустить. И единственным мерилом в данном случае является факт, который, как известно, упрямая штука. И вот я снова читаю на ночь книги по статистике и смотрю на курсере стенфордские курсы по машинному обучению. Всё это было, просто с каждым годом я нахожу этому всё больше применений. Те, что я видел несколько лет назад, те, что нахожу теперь… всё больше и больше.

Недавно я говорил с одним из своих pm-ов и натолкнулся на странное: он не видел своего результата, не мог сам себе доказать правильность и нужность того, что он делает. И я предложил посчитать. Посчитать наивно, в лоб, с точки зрения владельцев.

Любая коммерческая компания в конечном итоге имеет только одну метрику своей успешности: прибыль. Всё, что мы делаем, так или иначе нацелено на увеличение прибыли. Это не обязательно прибыль сиюминутная, но это всё равно прибыль. И тут важно помнить, откуда она берётся. А это крайне простая вещь — разница между доходами и расходами. И вы можете работать наружу, на клиентов, тогда, практически наверняка вы главным образом наращиваете прибыль за счет увеличения входного потока, а можете — внутрь, на своих сотрудников, на продукт, на процедуру его эксплуатации. И это всё равно увеличение прибыли, только через снижение расходов. И даже если не видно внешнего результата… просто смотрите на метрики и верьте в себя. И в цифры.

Продуктовая разработка, будучи противопоставленной разработке заказной, для меня имеет огромное множество плюсов. Тут и возможность полноценно погрузиться в задачу, и долго и вдумчиво итерация за итерацией совершенствовать и развивать проект, и непосредственное взаимодействие с конечными пользователями, и отсутствие внешнего прописанного в договоре срока, к которому так или иначе, хочешь не хочешь, пусть и ценой недоделок надо запустить проект. Прописанный срок регулярно приводит к гонкам, выкидыванию тестирования и отладки (да, срок и функционал прописан в договоре, а вот тесты… кто ж их кроме программеров видит), запуску откровенно сырого и нежизнеспособного продукта. Зачастую менеджеры творят просто чудеса в убеждении заказчика, что на самом-то деле всё работает.

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

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

Следствием являются потеря фокуса и снижение скорости развития, команда погрязает в мелочах, вместо того, чтобы расходовать свои силы на что-то действительно важное. Это же приводит и к потере тонуса: когда ты изо дня в день чем-то занят, но по прошествии недели, месяца, года, тебе не на что показать и с гордостью сказать “это сделал я”, это демотивирует. А затем расслабленность становится настолько привычной, что в случае необходимости уже не напрячься: отвыкли, разучились.

Я не говорю о том, что и здесь надо биться за запуск в срок любой ценой: если функционал откровенно сырой или ненужный, в чем смысл его запускать?! Но цель и срок должны быть, должны быть всегда, даже если позабыть про внешние факторы в духе уже назначенной даты старта проплаченной рекламной компании, прописанных в законодательстве сроков сдачи отчетности и т.д. и т.п. Да, я против навязанных сроков, но объем надо оценить, поставить дату и держаться за неё, держаться максимально точно. Это нужно всем. Да, и вам тоже.

Есть один простой, но почему-то не так часто используемый в наших палестинах способ совершенствования качества сервиса. Он настолько банален, что и говорить как-то неудобно: Eating your own dog food, т.е. по простому — использование собственных сервисов сотрудниками компании. Чаще всего эта политика используется в софтверных или технологических компаниях, что и понятно. Если вы видите сервис, в котором есть огромное количество мелочей, которые облегчают жизнь и появляются ровно в тот момент, когда они нужны… что ж, команда любит свой сервис, а кто-то уже достаточно эволюционировал, чтобы думать не только на уровне кода, но и интерфейса. Правда, будем честны, есть и другая крайность: типично “программерский дизайн” — это как раз, если этот шаг сделан не был, и весь интерфейс представляет собой бешенную мешанину контролов, художественно разбросанную по экрану. Впрочем, не об этом сейчас речь.

читать дальше »