​Cycle time

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

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

Как снизить cycle time:

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

Измерить cycle time можно в джире с помощью отчетов control chart и cumulative flow diagram. В клауд и next-gen джирах их отчетов нету, там достать эту цифру можно только через запрос в базу.

​Похвала

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

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

Получается, что похвала - это такой же инструмент управления проектами, как настроенная джира или подробное ТЗ.

На моей прошлой работе был один топ-менеджер. Столкнешься с ним бывало в лифте, а он скажет "о, Рома, круто вы сделали то-то и то-то, молодцы".

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

Короче, хвалите друг друга. А вот пара очевидных советов:

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

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

- Хвалите при свидетелях. Это х2 к силе действия 😉

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

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

- Мы мобильны и можем работать откуда угодно. Многие компании перевозят ключевых сотрудников в соседние страны, чтобы бизнес не вставал, когда отключают интернет. Это быстро и просто - самолеты до Киева летают три раза в день.

- Люди объединяются и помогают друг другу в тяжелые времена. Компании дают дополнительный отпуск пострадавшим сотрудникам. В линкедине десятки постов про бесплатное переобучение и менторство для силовиков. Даже заказчики входят в положение и не сердятся из-за задержек в поставках.

Держитесь, друзья. Надеюсь, скоро все закончится.

​Asana

На моем новом месте работы используют Asana. Предыдущие 5 лет я провел в Jira, поэтому сначала это казалось трагедией. Спустя 2 месяца ежедневного использования, готов поделиться наблюдениями.

Минусы:
- Очень базовые отчеты. Красивые графики есть, но толковой аналитики на них не построишь.

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

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

- Слабый функционал поиска. В джире ты чувствуешь себя богом, способным заглянуть в самые темные закоулки беклога. С помощью JQL (встроенный язык поиска в джире, похож на SQL) можно найти любой тикет. Из трех раз, что я что-то искал в Asana, нашел только один.


Плюсы:
- Asana работает быстро, разница с Jira видна невооруженным взглядом. Интерфейс свежий и вылизанный. По ощущениям это как перейти с Windows XP на Mac с ретина дисплеем 🙃

- Задачи можно держать в нескольких проектах одновременно. Это мегаудобно, например, когда 2 команды делают одну фичу.

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

- Есть простой Гант чарт, в котором можно вести роудмап или делать визуализацию планов.

-------

Asana проигрывает Jira по функционалу, но на голову впереди в плане удобства использования. Она подойдет маленькому стартапу, но большой компании в ней будет неудобно.

​Как качать технические навыки, ч2

Недавно я пришел в новую компанию, которая делает мобильное SDK. Здесь большая часть разработки это нейросети, С++ модули и немного мобил. После 7 лет в вебе, я как будто попал в первый класс 😀

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

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

📌 Нарисуй дизайн (архитектуру) продукта, над которым сейчас работаешь. Узнай для чего нужен каждый компонент, с точки зрения бизнеса. Что будет, если его убрать? Почему выбрали именно MondgDB, а не Redis?

📌 Потренируйся на вопросах дизайн-интервью. Это задачки, в которых нужно построить схематичную архитектуру приложения, например, Youtube или Skype.

📌 Читай Хабр, Медиум, Dou, в общем, любой технический ресурс, который нравится. Мне очень заходит подкаст Запуск завтра, в котором объясняют сложные инженерные штуки простым языком. Это формат интервью с гостями из легендарных компаний, вроде Сбера, Авиасейлз или Спотифая.

​Инфраструктурные баги

В тестировании есть хорошее правило - проверять баги на окружении, максимально приближенном к реальному.

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

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

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

​Изменения не бывают быстрыми

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

Чтобы приучить себя бегать или читать перед сном - нужна система и терпение. Ведь самое сложное - это не забросить через неделю. 

Так же и в разработке. Хочешь приучить команду писать тесты? Убеди тимлида, сделай презентацию для команды, опиши процесс и примеры тестов на вики, создай инфраструктуру, сто раз напомни в пулл реквесте “хороший код, не забудь еще добавить сюда тестов”. И жди. Через пару месяцев тесты станут частью рутины. 

Если раньше сам писал тесты, то кажется, что сложного взять и всем начать их завтра писать?

Но так не работает.

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

Продукт vs аутсорс, часть 1


" Я сейчас задумываюсь о переходе, куда посоветуешь идти, в продукт или в аутсорс?"

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

--------------------------

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

📌 Почему вообще компании отличаются

Все начинается с того, что компания продает. Это определяет законы и правила игры.

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

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

📌 Обучение

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

Зрелые фирмы (200+ человек) часто открывают внутренние программы обучения. Здесь всегда есть центры компетентности, во главе с гуру джавистом, которой знает ответы на все вопросы. Это огромный плюс для неопытных ребят. Когда я попал в такую компанию, за полгода я прокачался больше, чем за предыдущие 3.

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

​📌 Культура

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

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

С другой стороны, здесь всегда можно сменить проект и попробовать что-то совершенно новое в плане технологий или домена, если стало скучно. Помните, как Майкл Джордан на пару лет перешел из баскетбола в бейсбол? Вот это типичный случай в аутсорсе.

Продукт vs аутсорс, часть 2

📌 Технологии

Аутсорсеры предлагают то, что просит рынок - популярные технологии. Поэтому на любом аутсорс-судне легко найти отдел .Net, PHP и Javascript. Все новые проекты, которые пишут с нуля, будут использовать последние версии библиотек и фреймворков.

Технологии в продуктах выбираются под задачи, которые решает бизнес. В стартапах будет примерно такой же стек, что и в аутсорсе. Но чем старше бизнес, тем более старые там будут технологии. Банки, страховщики и телеком с легкостью переместят вас в недалекое прошлое, показав как писали отличные программы на Cobol, Perl и Fortran 🙃.

В одном продукте, где я работал, часть бекенда была написана на Coldfusion. Это настолько редкая технология, что на весь hh.ru висит всего 2 вакансии.

📌Процессы

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

Такие компании растут только вширь, увеличивая штат. Чем оптимальнее будет процесс, тем меньше уйдет часов сотрудника, тем меньше будет затрат. Меньше затрат - больше прибыль и быстрее рост.

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

📌 Зарплата

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

И тут и там платят за скилы. В продукте ценится доменный опыт, т.е. умение решать похожие задачи. Если вы поработали 3 года в Авито, то такой опыт оценят в любом маркетплейсе - от Яндекс.Еды до Авиасейлз. А вот перейдя в банк, эти знания уже будут не так релевантны, поэтому офер может быть меньше.

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

​Вместо заключения

Поработав в двух аутсорсинговых и двух продуктовых компаниях, я понял для себя следующее. Продукт или аутсорс, разницы никакой, и там и там придется работать с людьми 😉. Поэтому выбирайте с кем будет комфортно тратить 40 часов в неделю.

​Новая версия Scrum guide

2 недели назад анонсировали новую версию Скрам гайда. За 25 лет существования фреймворка, он менялся всего несколько раз и каждый раз это большое событие в мире Эджайла.

Следуя тренду последних лет, Cкрам стал более инклюзивным. Из гайда убрали слова тестирование, релиз, система, характерные для мира разработки софта. Людей из других сфер, которые только пробуют фреймворк, отталкивали эти термины, мол "у нас такого нет, поэтому Скрам нам не подходит". По этой причине их заменили на более нейтральные 🤐.

Сам текст будто бы прогнали через сервис glvrd.ru - он сократился с 19 страниц до 13, став менее формальным и более дружелюбным.

В этом же и минус новой редакции - общие фразы не объясняют как именно использовать Скрам. Например, в Sprint Review раньше были конкретные советы как проводить митинг: проходиться по done, обсуждать ситуацию на рынке, релизы, бюджеты. Теперь все это упразднили.

❗В новой версии есть одно действительно важное обновление.

Раньше у команды была только Sprint Goal - микро-цель на ближайшие 2 недели. Теперь все микро-цели собираются в одну большую-мега-цель Product Goal, ради которой все затевалось. Такая цель очень нужна продактам, потому что помогает ответить на вечные вопросы "какой продукт мы строим и для кого?", на которых потом строится весь продакт-менеджмент.

Изменений в новом гайде много (полный список), но большинство из них косметические - это все тот же старый добрый Скрам.

​Как найти классную работу

Весной я решил сменить работу. Сделал резюме, обновил линкедин и стал думать куда идти. Компаний на рынке много, как понять в какой классно?

На примете было несколько мест, о которых я слышал хорошие отзывы. Еще пару компаний я нашел на основании:

✅ отзывов друзей, которые там работают;

✅ советов знакомых эйчаров. У них есть картина всего рынка, они много знают о других компаниях;

✅ кнопке "кто из контактов в линкедин работает в этой компании". Если где-то работает несколько человек, которых я знаю как крутых спецов - это весомый показатель того, что и фирма хорошая. Зачем классным ребятам трудиться в неклассном месте, верно?

✅ отзывов и обсуждений на дев бае, а также новостей об этой организации по тегу. Украинские компании смотрите на доу. Для российских гуглите "название компании + отзывы".

Так я составил список мест, где хотел бы работать.

P.S. Если вам интересно какие продуктовые компании Минска попали в мой субъективный шорт-лист - напишите в лс. Публиковать его тут не совсем правильно.

​Если сделали несколько оферов

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

Как настоящий п̶р̶о̶д̶а̶к̶т̶ зануда, я решил составить табличку скоринга - критериев, которые важны на новом месте (это не только зп!!). Результат на скриншоте.

Заполняю такую уже во второй раз и снова наблюдаю один эффект. Когда она почти готова, приходит четкое понимание "ой, да что тут думать, конечно, Компания Х". Не знаю как это работает 😆

​2020 -> 2021

Друзья, с наступающими праздниками! Желаю вам:

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

Вы, конечно, знаете, что во всем остальном мире больше празднуют католическое Рождество, чем Новый Год. Не забудьте поздравить своих клиентов на этой неделе! Если совсем нет вдохновения придумывать слова, вот вам темплейт:

Dear Matt,

This was a really challenging year and we have made a lot of great things together. Looking forward to the next one, sure it'll be even more fun!

Our team wishes you strong metrics, enthusiasm for you team and a bunch of happy customers.

Merry Christmas to you and your loved ones!

Как описывать задачи: подробно или коротко?

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

📌 автореплай на отправленное сообщение отправлять с почты ...
📌 запрашивать номер телефона и валидировать по правилам ....
📌 максимальный размер прикрепляемых файлов 5 МБ, минимальный 1, поддерживаемые форматы..... Если формат не поддерживается, выводить сообщение....

Ну вы поняли.

Это все очень толковые вопросы. Благодаря ответам на них, программистам и тестировщикам не придется думать над задачей, а просто делать по инструкции. Их оценки будут достаточно точными, но они могут подумать, что не влияют не продукт, который строят: "делаем, что скажут".

Другой менеджер потратит 5 минут и опишет задачу общо:

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

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

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

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

📌 через форму поддержки продавцам будут приходить письма с уточнениями о заказе, предположительно 50-100 в день.
📌 пользователи будут оставлять жалобы о товаре с фото, поэтому нужно прикреплять файлы

А как вы описываете задачи?

​Рецепт идеального спринта

Если продакт-оунер где-то загулял, а спринт пора начинать, берите инициативу в свои руки и планируйте загрузку команды примерно так:

40% - новые фичи;

15% - технический рефакторинг: удаление и переделка старого кода, долги по тестам, CI;

15% - бизнесовый рефакторинг: доработка и улучшение уже выпущенных фич;

10% - багфиксинг: ошибки приложения, которые не вошли в предыдущие два пункта. Ошибки новых фич рекомендуется закладывать в первые 40%;

10% - разработка, а-ля RnD: проверка гипотез, прототипы фич, всякие пруф оф концепт для клиентов, попробовать новые библиотеки и фреймворки;

10% - запас на случай непредвиденных задач (а они будут);

------------------------------

Если этот рецепт вам не подходит, держите упрощенный, работающий во все времена:

❗Делать надо те задачи, которые приносят деньги. А те, что не приносят - не делать.