Управление и команды

Я предлагаю профессиональные консультации для руководителей разработки и программистов.

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

Договорённости в разработке и с продуктом/бизнесом, менеджмент ожиданий, найм и увольнение программистов, сроки, деньги, СТРАХИ. Все мы сталкиваемся со сложностями в работе. За 7 лет руководства разработкой я набил много шишек и хочу вам помочь.

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

3500руб в час, очные консультации в Москве и в Риге или по видеосвязи. Гарантирую конфиденциальность. Интим не предлагать.

Запись тут: https://calendly.com/samatg/video-consult, вопросы в личку.

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

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

Basecamp — не идеальный инструмент. В нем нет канбан доски как в трелло, в которой удобно двигать задачки по статусам от «идея» до «готово». В нем нет кастомных представлений как в жире, в которых удобно посмотреть все iOS-баги, находящиеся в тестировании и назначенные на определенного человека. В нем нет мощного чата, как в слеке (ох как хочется затегать группу!). В нем нет красивого редактора, как в Notion, даже таблицу в задачу не заведешь. В нем нет древовидных комментариев, как в жире и Confluencе, а ведь так хочется ответить на определенный комментарий в треде). И уж конечно это не супер футуристичная бесконечная коллаборативная доска как Miro.

Любым инструментом можно поддержать практически любой процесс разработки. Разница в том, какое поведение инструмент поощряет, а какое — наказывает, делает неудобным. В этом плане я доверяю создателям Basecamp.

Я хочу вести разработку как создатели Basecamp — качественно, стабильно, интересно, с уважением ко всем участникам процесса. Мне интересна тема ответственности и в Basecamp она очень важна.

Если вам стало интересно, как это — вот несколько книг, объясняющих их подход:
- методология разработки — Shape Up;
- одна из главных книг про удаленную работу — REMOTE;
- как не сгореть на работе — It Doesn't Have to Be Crazy at Work!

Рекомендую.

Давно я не писал откровенно, когда плохо.

Сегодня вот хороший разработчик сказал, что уходит в другую компанию. Мне очень больно - думаю, что это из-за моих ошибок.

Одна из озвученных причин - что я игнорировал его несогласие. Он несколько раз говорил, что не видит impact (пользы) в паре задач, а я замял этот вопрос. Не будьте как я, решайте подобные вопросы от разработчиков тем или иным способом не откладывая.

Любое решение лучше, чем игнорирование 🌙

Мы подкаст сделали!

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

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

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

Какая самая сложная вещь в работе техдира? Что происходит, когда твое приложение — №1 по популярности в американском аппсторе? Это и многое другое в первом эпизоде. Подписывайтесь: Apple, Google, Castbox, RSS или в Яндекс.Музыке!

Спасибо большое дорогому редактору Андрею Борзенко, звукорежиссёру Павлу Цурикову, продюсеру Павлу Боровкову, композитору Алексею Зеленскому, дизайнеру обложки Пете Сутупову и лично Лике Кремер! Без вас и студии Либо/Либо подкаст бы не получился.

Похвастаюсь: ко мне на работу в Pure пришел бэкендер Антон Шурашов и начал приводить бэкенд Pure в чувство.

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

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

Спасибо всем, кто откликнулся на вакансию. Познакомились с несколькими интересными специалистами, надеюсь ещё поработаем вместе. 🍒

Представьте, вы - столяр. Перед вами свободный рабочий стол, вокруг по порядку расставлены инструменты. Это рабочее место профессионала.

Теперь представьте: стол стоит на попах, чтобы не завалился — его подпирают инструменты; вокруг грязь.

К сожалению, отличить эти две ситуации в IT неспециалисту не просто.

Оценить скорость работы в IT, её объем — очень трудно.

Следите за качеством. Качество — надежный и заметный неспециалисту прокси инженерной культуры. Если качество страдает — значит под техническим капотом и в процессах есть проблемы.

> Очень классное исследование про врачей хирургов. Камеры записывали видео операций. Отличить хорошего хирурга от плохого может любой. У хорошего хирурга швы аккуратненькие, рука будто летает по полю. И пациенты выздоравливают лучше.

—

Почему ломается инженерная культура? Я знаю две основные причины:

1. Руководители не дают времени на наведение порядка. Вина в таком случае обычно не только на руководителе, но на и на инженере, который не смог донести важность _рефакторинга_ (это термин для наведения порядка в IT). Классический рецепт катастрофы: продакт знает, каких изменений хочет в продукте, а про технологии понимает мало, умеет убеждать; технари плохо доносят необходимость постоянных инвестиций в наведение технического порядка. Говорить с бизнесом о своей работе понятным языком — часть профессиональной компетенции программиста. 🧨 Быстрый способ: не доверять программистам, считать, что они идиоты и/или не иметь с ними диалога.
2. Технари недостаточно компетентны и оказываются погребены под сложностью монстра, которого сами соорудили. Бонус очки, если инженер имеет завышенную самооценку и/или боится признаться в ошибке.

——

Что делать?

Хорошо бы исправить ситуацию с текущими программистами. Они обладают знанием вашей системы, вашей предметной области. Это дорого стоит

Инженерная культура для программиста — это про самоуважение и уровень профессионального развития. Я не знаю, как вернуть самоуважение. Я не знаю, как вернуть человеку потерянное чувство брезгливости, продолжая находиться в грязи. .

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

———

Мне везло работать в компаниях, где с инженерной культурой всё ок. Сделать в Pure классно — для меня профессиональный вызов. Интересно и сложно.

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

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

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

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

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

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

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

☙

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

Ищете программиста? Я начинаю с того, что пишу описание вакансии, которое не стыдно показать классным кандидатам. Во время редактуры становится яснее, кто же нужен.

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

Вопросы, на которые я стараюсь ответить в тексте:
- для чего вы ищете человека
- с кем он будет работать
- кто будет пользоваться результатом его труда
- сколько вы хотите платить за работу
- есть ли какие-то особенные условия, о которых стоит знать?

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

Вот пример вакансии до и после редактуры.

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

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

https://t.me/pmdaily/343

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

Basecamp написали подробную книгу, как они строят свою работу.

Эти ребята умудрились вырастить продуктовую компанию из 2 человек в 50 и не потерять при этом жизнь, скорость и кайф в том, чем они занимаются.

Всё бесплатно, онлайн, с примерами из реальной жизни.

💘 https://basecamp.com/shapeup