​Стоимость владения

6 лет назад я купил свою первую машину - бирюзовый мини купер. Спонтанно, эмоционально, за один день. Снял первые и последние $4,000 с карты и обменял на ключи.

В тот момент мне казалось, что купить машину, это то же, что купить велосипед - насобирал денег, заплатил и катаешься. Мир оказался сложней. Теперь надо тратить еще минимум $100 каждый месяц на бензин, мойку, стоянку, масло и так далее по списку. Ауч! 🤦‍♂️

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

По моим внутренним ощущениям, стоимость владения где-то x2 - x3 от стоимости разработки в год (у нас продукт SDK, в б2с, наверное, меньше). То есть, за фичу, на которую потратили 100 часов, придется заплатить за обслуживание еще 200-300 сверху.

А сколько у вас?

​Еще про стоимость владения

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

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

1. Выкидывать неиспользуемые фичи и код (безжалостно).
Если фича не приносит бизнесу денег, ее надо просто закрыть. Как говорят, лошадь сдохла - слезь.

2. Пользоваться готовыми решениями.
Представьте, что заказчик просит сделать ему клон Тиктока. Среди фич есть съемка и видео редактор - довольно большой кусок проекта. Можно потратить 4 месяца, $300K и кое-как написать его с 0. А можно купить готовый SDK за $30K в год и втянуть к себе за неделю! Прежде чем взяться за новый, масштабный проект, исследуйте, нет ли на рынке готовых решений.

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

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

​Писать простые решения

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

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

❗Поэтому надо прогать то, что бизнес просит прямо сейчас, сегодня. Конечно, стоит держать в уме, что может понадобиться в ближайшей перспективе. Но необязательно сразу проектировать на столетия и все случаи жизни.

Представьте, что клиент заказал дейтинг приложение. У него пока нет пользователей, он только запускает новый продукт. Одна из фич приложения - чат. Как ее лучше делать?

Можно взять готовый чат-движок XMPP, развернуть на самом дешевом T2 серваке амазона да прикрутить юай. На все про все уйдет 2 недели. Будет работать кривоватенько, но свою задачу выполнит.

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

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

В том, чтобы применить нужную сложность есть очень большое мастерство в программировании. И менеджменте.

​Дать сохранить лицо


Этой штуке я научился совсем недавно у моего тимлида Глеба.

Нам попался очередной нервный заказчик, очень дотошный и требовательный. Один из тех людей, которые пишут "вы мне испортили все приложение!" (а иногда еще и жизнь).

Клиент выносил мозг по каждой мелочи. Найдет съехавшую кнопку и все, тревога, письмо СЕО, бросайте все свои дела и немедленно чините, я не могу выйти в продакшн! Каждое такое сообщение сопровождалось комментариями о нашей компетентности, качестве продукта и все в таком духе. Работать было неприятно.

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

Я торжествовал. Вот сейчас, *дорогой клиент*, я поставлю тебя на место, в твоей же любимой ехидно-снисходительной манере. Уже перебирал в голове эпитеты, которыми награжу его, как вдруг позвонил Глеб. "Я написал им в личку, показал где они косякнули. Он проверил код, все, естественно, завелось. Даже извинился (скриншот)".

Попричитав, что Глеб лишил меня приятной мести, на следующий день я был благодарен ему, когда остыл. Он дал клиенту сохранить лицо, и не ввязал нас (и меня в первую очередь) в ненужную войнушку. Клиент с тех пор как будто даже стал меньше козлиться.

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

PM стрим со мной

На прошлой неделе сходил на стрим о ПМстве в роли спикера.

Там у всех директорские роли (кроме меня 🙊). Это как раз те, кто сегодня нанимает проджектов в Минске. Если думаете менять работу, то обязательно послушайте кого ищут в 2021 из первых уст.

Темы все насущные:
- как стать PM, что делать, кого читать и у кого поучиться;
- что происходит с методологиями в пандемию;
- роль Delivery manager и чем она отличается от PM;

Запись можно посмотреть тут: https://youtu.be/7vxs9ClL-Vs

​"Ясно, понятно"

- это последняя книга Максима Ильяхова, автора "Пиши, сокращай" и "Новые правила деловой переписки".

Я очень советую ее прочитать менеджерам и всем, кто работает с клиентами. Она помогает прокачать наш самый важный навык - коммуникацию.

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

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

Представьте, что делаете спринт репорт для своего босса. Там допустимо написать, что программисты балбесы (бывает и такое). Но этот же самый отчет у заказчика вызовет недоумение. Жалуетесь на своих собственных программистов? Для клиента такая версия отчета не пойдет, в ней много внутряка, который ему знать не нужно.

Берегите контекст, читайте "Ясно, понятно".

​Обещать меньше, делать больше

Когда я начинал работать ПМом мне тяжело давались переговоры с клиентами. Боялся, что заказчик подумает что мы лохи, не умеем делать сайты, развернется и уйдет. Всегда хотелось выглядеть представителем серьезной, опытной студии, использовать крутые технологии. Например, делать А/Б тесты.

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

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

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

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

​Какие отчеты делает менеджер

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

1️⃣ Sprint report. Что сделали за последние 2 недели, что не сделали, всякие графики, риски. Пример.

2️⃣ Потраченный бюджет для клиента. В этом отчете говорится сколько часов и денег потратила команда на задачи в проекте за период. Обычно делается раз в месяц, чтобы на его основе выставить счет клиенту. Пример.

3️⃣ Потраченные часы сотрудников для компании. Почти то же, что и предыдущий, но с поправками на невыставленные часы. Иногда бывает так, что за некоторые работы, клиент не платит. Например, если в фикс-прайс контракте прописан месяц поддержки. Тогда команда чинит баги после релиза бесплатно. Эту разницу "выставлено клиенту" / "сделано бесплатно" надо учитывать для финансистов компании, что и отражает этот отчет. В продукте его тоже делают, чтобы посчитать затраты на собственную разработку.

4️⃣ Incident report. Когда на продакшене беда, все суетятся и думают как починить проблему. На следующий день, когда страсти поутихнут, надо подвести итоги потерь. Пример недавнего аутэджа у Фейсбука.

5️⃣ Отчет по разработанным фичам. Иногда работаешь на российскую фирму, а деньги из апстора (или от клиента) приходят на дочернюю компанию, например, в США. Так делают, чтобы не держать деньги в наших банках. Так вот, в этом случае российское юрлицо передает права на разработку американскому, как будто одна фирма наняла другую. Отчет странный, но встречается часто.

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

Когда сходил на конференцию и разбираешь заметки

​Project vs Program manager

Если вы присматривались к работе в продуктовой компании за пределами СНГ, то замечали, как редко там встречается должность project manger. ПМов на западе действительно меньше.

Обычно их заменяют связкой engineering manager (тимлид + немного менеджерских обязанностей) + product manager.

В больших продуктах есть похожая на проджекта роль - program manager. Это человек, который отвечает за большую инициативу, в рамках которой делают несколько проектов. Например, программ в Gmail может отвечать за интеграцию гугл рекламы Adwords и координировать работу 2 команд из разных продуктов - Adwords и Gmail.

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

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

Это интересная работа, если вы устали от операционки на уровне баг-стори и готовы к масштабу уровня релиз-роудмап.

В блоге Atlassian очень понятно объяснили, чем отличаются эти две роли:

Буддисты и автоматизация

Это буддийский молитвенный барабан. На его поверхность наносят тексты священных писаний. Считается, что когда покрутишь барабан, то молитва как будто прочиталась.

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

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

​Ходить по собесам

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

Я думаю, что нет, т.к. мы с вами на рынке труда, со всеми вытекающими последствиями. Работа - не романтические отношения, где любовь до гроба и пока смерть не разлучит нас. Поэтому распространенный аргумент о лояльности компании все-таки мимо. Такие устои морально устарели, сейчас все меняют работу раз в 2-3 года (не берем в рассмотрение директорские роли и выше, для них другие правила игры). Ну и если компания с тобой честна, то никак не пострадает от того, что ты выяснишь свое положение на рынке.

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

1️⃣ Уверенность в себе и завтрашнем дне. Когда поступает пару предложений в месяц, то понимаешь, что не пойдешь по миру, если на текущем месте что-то пойдет не так. Так избавляешься от зачатков синдрома самозванца, когда думаешь, что компания делает тебе одолжение, давая работу.

2️⃣ Знание своей стоимости на рынке. Когда тебе предлагают +-300 долларов в районе текущей зп, то все ОК. Значит, сейчас ты получаешь свою честную, рыночную зп. Всегда будут места, где трава чуть зеленее. А вот если предлагают +700 и больше, и сразу в нескольких компаниях, то есть повод задуматься. Цифры условные, у всех разная зп, лучше, конечно, в процентах считать.

3️⃣ Понимание, каких знаний сейчас не хватает до следующего карьерного скачка. Иногда собеседование заканчивается отказом. Это нормально. Когда получаешь отказ, значит недотягиваешь до позиции, на которую хочешь. Отлично! По вопросам, которые задают, и финальному фидбеку можно хорошо порефлексировать и составить план роста.

Мне хватает 2-3 интервью в год, чтобы иметь более-менее ясное представление о себе и "оставаться в форме".

А вам?

​Неприкосновенность оценки

В зрелых инженерных организациях есть принцип неприкосновенности оценки. То есть то, что команда оценила в 2 месяца, ставится в план как 2 месяца. Нельзя просто придти и сказать, "мне пофигу, сделаете за месяц". Нет никакого смысла ставить месяц, все равно ведь не сделают.

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

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

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

Всем известно, что Стив Джобс, например, тот еще булли. Он уволил чувака, который засомневался, что тот сможет создать коммерчески успешную мышку. Возможно, благодаря такому подходу Эпл и создала столько крутых продуктов. Говорит ли Илон Маск "мне похер как эта штука взлетит, но за 3 недели, или вы все уволены"?

​Я тебя услышал

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

As per my last email = In case you didn't fucking read what I wrote before;

To reiterate = I'm not fucking saying it again;

Thank you for your input = No one fucking asked you;

Moving forward = That was the last time this shit came over;

As a kindly reminder = In case you fucking forgot;

Hope this email finds you well = Honestly, don't give a fuck about your life;

How can I help you to solve it? = This takes too fucking long. Solve it fast, I don't care how;

Best regards = тут либо fuck you, либо wish you the best, как повезет;

Как держать беклог чистым

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

Аналогичное правило можно применить и для беклога. У нас в команде оно звучит так:

❗❗ Если задача занимает меньше получаса, то делай ее сразу, не заноси в беклог.

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

К тому же экономится время на фокусе и контексте. Пока разработчик работает над фичей, ее устройство у него в "оперативной памяти". Правочки вылетают из Xcode, как горячие пирожки.

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

​Еще один приемчик:

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

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

У нас такой список называется "Postponed bugs". В нем около 30 задач, в то время как во всем беклоге в районе 150.

​Лайфхаки в SaaS

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

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

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

Сервис предлагает два варианта:
- "Написать в поддержку (среднее время ответа 1-2 бизнес дня)" или
- "Узнать в центре знаний (6-7 минут)"

Трюк здесь в том, что у всех SaaS есть и поддержка, и центр знаний (это обычный FAQ). И все отвечают примерно за 2 дня. Но hotjar с помощью трех слов о скорости ответа сделал второй вариант очевидно более привлекательным. В него будут чаще конвертиться, и меньше писать в саппорт. С такой формулировкой даже лентяй вроде меня задумается, стоит ли ждать 2 дня, если можно получить ответ почти сразу, поискав на сайте.

👍 Лайк!

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

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

👍👍 Суперлайк!

​Стадии развития команды

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

❗❗ Каждая команда с первого дня пройдет 4 стадии роста: forming, storming, norming, performing.

Давайте рассмотрим каждую из них.

👋 Forming
На первой стадии все учтивы и доброжелательны, присматриваются друг к другу. Конфликтов избегают. Людям хочется произвести хорошее впечатление, поэтому они работают чуть лучше и больше обычного. Для менеджера это главное время зарабатывать авторитет и устанавливать границы что можно, а что нельзя.

🖕 Storming
Игра престолов начинается здесь. Люди поняли, кто чего стоит и потихоньку начинают разыгрывать локальные войнушки.

Кто-то уйдет: "в гробу я видал такого тимлида!".
Кто-то отмалчивается: "сами как-нибудь разберутся, зп капает и ОК".
Кто-то проталкивает свои идеи: "я в прошлой компании писал на vue.js, проект взлетел, давайте и тут все перепишем".

На производительности это сказывается плохо, из-за споров и разногласий работа делается долго.

🤝 Norming
Рано или поздно, народ устает выяснять отношения и кто-то вспоминает, что пришел сюда решать задачи. Люди потихоньку начинают слушать друг друга, договариваться, искать компромисс. Появляются ростки доверия и эмпатия. Как следствие, растет скорость закрытия задач.

На этой стадии ПМ уже задумывается о делегировании.

💪 Performing
На ретроспективе все чаще слышно "у нас сильная команда, все друг другу помогают". Шишки набиты, ответственность распределена, все знают что и как работать. Уйти в отпуск на 3 недели не проблема. Функция менеджера тут поддерживающая. Без него не обойтись только во внештатных и критических ситуациях.

Вот и все, теперь вы знаете модель Такмана.

--------------------------------
Картинка отсюда

Зачем это надо

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

Например, на форминге ОК сказать: "так, я все обдумал и решил, гребем вот сюда". А в другой момент, на перформинге: "ребята, вы уже взрослые, я вам доверяю, решайте сами, куда грести". Так помогаешь команде быстрее придти к следующей стадии.

👉 По моим ощущениям, перейти от первой стадии на последнюю у новой команды занимает от 6 месяцев до года.

А по вашим?

​Почему необязательно отвечать на сообщение или письмо, как только оно пришло

Вот почему: