#ответственность

Что отличает хорошие команды разработки от плохих?

Единого правильного ответа нет — команда это инструмент решения задач бизнеса и каждой задаче свой инструмент. А еще это вопрос ценностей.

Для меня в разработке важны два принципа, из которых можно вывести все остальное:

1. Заинтересованность в конечном результате. Способность и настроенность не «работу делать», а «получать результат, двигаться к результату». Не путать с горящими глазами! Восторженность не обязательна, но безразличие опасно.

2. Предсказуемость. Раньше я называл это «способность выполнять обещания», и это простой критерий, но как и любую формальную метрику его можно обмануть — например, не давать обещаний. И очень уж фонит трудным детством в казанских кварталах: «пацан слово дал» и вот это все. Предсказуемость включает в себя выполнение данных обещаний, но еще и прозрачность, проактивное обсуждение возникающих трудностей (а они точно будут), формирование реалистичных ожиданий.

А что для вас главное в разработке? Интересно, будут ли отличаться ответы разработчиков и продактов, бизнеса? Пишите пожалуйста в чатик @ctodailychat или в личку @samatg

Никогда ещё я не работал так много, как в последние 2 недели.

Первые месяцы в Медузе были похожими, но тогда я очень сильно боялся. Боялся испортить отношения с программистами, боялся совершить ошибку. Это, конечно, мешало работать в полную силу (и занимало большУю часть моей психотерапии). В результате я мало делегировал.

Теперь я боюсь меньше. Ставлю вопросы ребром, увольняю, выражаю недовольство и хвалю. Причин изменения поведения три: 1) я теперь знаю, что из любой ситуации есть выход, 2) нет смысла врать и притворяться, лучше говорить как знаю и как чувствую, 3) я довольно много повидал всяких технических штук и продуктовой работы, не боги горшки обжигают, как-нибудь прорвемся. Ещё одна важная причина — Рома (владелец бизнеса) не дает скучать и жестко, но справедливо спрашивает :)

Моя задача сейчас — это сделать из 16 специалистов (3 iOS, 2 Android, 3 бэкендеров, 3 фронтендеров, 2 дизайнеров, 2 тестировщиков и сисадмина) крутую продуктовую команду. Команда, в отличие от набора специалистов, решает задачи сообща, слаженно.

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

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

Недостаточно высказать эти лозунги. Нужно каждый день предлагать, требовать, не забывать контролировать обещания, выслушивать критику, тюнить процесс, правила игры. Это трудно, но безумно увлекательно. И я начинаю замечать первую положительную обратную связь. Такой кайф!

☙

Коллеги - технические руководители, давайте встретимся поговорим, поделимся опытом. Хочу устроить неформальный митап в Москве. Пара докладов и общение за едой. Записывайтесь в формочку, договоримся о дате и формате.

Федя бьет не в бровь, а в глаз. Благородный муж — не инструмент; с разработчиками нужно договариваться и объяснять, какого результата мы хотим достичь; делиться с ними ответственностью и властью.

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

https://t.me/pmdaily/343

Upd: коллеги в чате разумно замечают, что программисты диктующие условия - тоже путь к провалу. Гармония нужна! Синергия.

Насчет журналистской солидарности, в отсутствии которой меня уличают (https://t.me/mediasrachi/736) . Журналисты не при чем (неуиновны).

Налицо или халтура разработки: не протестировали ничего толком, не подготовились к нагрузке; или некомпетентность руководства, когда к разработке приходят с запросом «сколько тебе нужно времени, чтобы это было готово завтра?».

Извините, если выглядело как наезд, это не так. Это была серия постов «смотрите, как не нужно делать».

Запуск больших проектов — сложно и больно, но зато, в теории, есть время подготовиться. Супер-важно, чтобы руководство понимало, что «у меня всё работает» не равно «можно запустить на 100 тысяч пользователей». Ответственность разработки — объяснить важность тестирования. Вот вам бесплатный хороший кейс, на который можно ссылаться.