Комментарий к кейсу про доработку ^

Когда фича дошла до QA, в ней нашли миллион эдж кейсов:
- делаешь фото, в этот момент включаешь другую вкладку, апа крашится
- делаешь съемку с таймером, пока идет обратный отсчет, переходишь в другую вкладку, съемка продолжается (хотя юзер уже в другой вкладке ).
и т.п.

Все потому, что когда мы делали оценку, то думали о работе SDK только в контексте самого SDK. А механизм вкладок вносит доп логику снаружи. Благодаря ему юзер может одновременно использовать другие фичи приложения в других вкладках. Там может оказаться еще одна камера, еще одна вспышка, любой функционал, дублирующий наш, или, что еще хуже, противоречащих нашему. Это определенно вызвало бы "помехи", которые мы и начали ловить в эдж кейсах.

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

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

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

​1 картинка вместо 1000 слов

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

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

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

Как говорится, лучше один раз увидеть, что сто раз прочитать в тикете.

Что отличает джуна от сеньора? Самостоятельность

Джун-ПМ: Рома, мой кастомер спрашивал про перфоманс нашего приложения. У меня в команде этого никто делать не умеет. Что делать?

Сеньор-ПМ: Рома, мой кастомер спрашивал про перфоманс нашего приложения. Я сходил к ресурс-менеджеру QA, он нашел Петю Быстрова, тот умеет такое делать. Правда, он сейчас занят, но я договорился с Витей Меркуловым, его ПМом, привлечь его с 1 марта на 2 недели. Кастомеру выставим по 60$, спец редкий :) Подозреваю, что там все будет не очень хорошо по перфу на самом деле, поэтому щас пойду искать еще сеньорного джависта, который починит нам потом эти проблемки. FYI.

#джун_vs_сеньор

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

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

Война - это пиздец. Нет войне.

Ребята, предыдущий пост (он уже удалён) писал не я. Мой канал и многие другие каналы в тг взломали с помощью бота аналитики.

Сейчас доступ восстановлен, все хорошо.

​Кто тут наши

Мне повезло еще полгода назад переехать в Тбилиси. Сейчас многие ребята из России и Беларуси тоже сюда перебираются. Заметил, что местные начинают нас потиху хейтить.

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

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

Максим Кац, который много снимает про войну, задал очень уместный в этом контексте вопрос: кто тут наши? И правильный ответ тут один. Наши и те, и другие. Не наши здесь только кучка политиков, развязавшая войну. Но я уверен, что они с нами ненадолго. Они уйдут, а мы с вами останемся и будем как-то жить дальше.

Берегите друг друга.

​Плохие новости

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

"Нашим клиентом стала Тойота!"
"В прошлом квартале мы заработали на 30% больше денег, чем планировали!"

Это супер важная функция. Слушаешь топов и думаешь, о, супер, дела идут в гору, радуешься за фирму. И даже работать чуть хочется больше (на то и расчет).

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

"От нас ушли 3 ключевых разраба, мы не смогли их удержать"
"Проект Apple blossom не взлетел. Мы потратили кучу денег на его продвижение, но ошиблись в позиционировании"

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

На самом деле сотрудники все равно заметят уход ключевых разрабов и закрытие проекта. Только они еще додумают драматичных и пикантных причин, почему это случилось 🙃.

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

​Запрос на новую фичу

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

​Отключите уведомления

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

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

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

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

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

Не бойтесь отключить все пуши: смс, яндекс, слак, почту, телеграм, все, что найдете. Ну, кроме кроме мамы и бабушки в вайбере, конечно. Берегите свое внимание 😌

​Советы по change requests

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

Что ж, придется изучать блокчейн и МЛ 😁. А если у вас fix price контракт, то эти две фичи для проекта - change request (CR).

Вот несколько хороших практик по работе с такими изменениями:

1️⃣ Закладывайте время на оценку в стоимость CR. За обсуждение новых фич заказчик вряд ли заплатит, потому что это как бы пресейл, он обычно бесплатный. Но ведь нам нужно превратить хотелки в требования, погрумить их с командой, дать оценку. На все это тоже нужно время. Можно добавить потраченные часы к будущему контракту. Т.е. насчитали 100 часов на новую фичу, 4 потратили на оценку, выставляем клиенту 104 часа.
Если же изменение большое, как в примере выше, то его проводят как фазу discovery, уже платно.

2️⃣ Закладывайте старые косяки по бюджету в новые CR. Классика. Если часть проекта на старте недооценили и он ушел в минус, то совсем не стыдно часть недостачи заложить в новую оценку, чтобы улучшить баланс. Это вообще не грех, я узнавал.

3️⃣ Помимо оценки в деньгах, не забывайте про оценку сроков. Самое важное тут - проверить, как новый скоуп влияет на дату основной поставки. Обычно он как раз влияет, т.к. поменять просят что-то близкое по функционалу. Будьте внимательны здесь.

4️⃣ Если CR становится слишком много, предложите клиенту перейти на Time and Material - контракт, с оплатой за потраченные по факту часы. Тогда не нужно будет бегать за каждой оценкой и подписывать документы на любое изменение. Для обеих сторон это вин.

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

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

7️⃣ Когда заказчик даст аппрув на новую фичу, положите ваши договоренности на бумагу. Для каждого CR надо подписать два документа: scope of work, с описанием фичи и delivery acceptance, в котором заказчик эту фичу принимает. Если отношения с клиентом хорошие, то начинать работу можно и без подписанного договора, но иметь его все равно нужно.

Эти советы настоены на горьком опыте многих ПМов. Не повторяйте их ошибок 🙏

​Сколько времени тратишь на разработчика

Открою вам маленькую тайну.

В голове любого менеджера каждый разработчик имеет профиль, как в компьютерной игре. Там все его скиллы с какой-то оценкой. Типо, кодит на 5, ретроспектирует на 3.

Один из супер-важных параметров в этом списке - maintenance. Означает, сколько времени и усилий менеджер тратит на этого человека.

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

В каждой машине надо менять масло, но в одной раз в месяц, а в другой раз в три месяца.

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

Про первого говорят high maintenance, про второго - low maintenance. Менеджеры, конечно, больше вторых любят.

​Главная задача менеджера - хороший найм

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

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

На одном проекте я полгода выбивал разработчика от боженьки. В какой-то момент лёд руководства треснул (как и наша профитабилити) и нам дали Юру. У Юры было 17 лет опыта.

Он пришёл и за месяц порешал все проблемы, которые мы не могли решить год. Я не мог в это поверить. Юра просто брал и фиксил все самые дикие баги!

Один супер-профи может закрывать такой же объем работы, как несколько обычных разработчиков. Поэтому в Гугле и Фейсбуке такой жесткий отбор. Они набирают звезд-олимпиадников, чтобы выпускать свои продукты максимально быстро и качественно.

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

Здесь наша с вами задача - построить в голове руководства вот такую нейронную связь:

Экономия на команде = экономия на продукте.

Кейс про выбор кандидата

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

🧓 Игорь, 9 лет опыта:
- 2 года в продукте по видео-звонкам
- 4 в аутсорсе, на разношерстных проектах
- 3 в продукте по подбору автомобилей

🧔 Антон, 4 года опыта:
- 1 год в соцсети для собак
- 3 в стартапе по быстрому переводу денег

У вас есть один слот для интервью на этой неделе.

Комментарии к кейсу про выбор кандидата ^

Помимо стандартных навыков, компании ценят еще и доменную экспертизу. Это знания в области, на которую нацелен продукт. В нашем примере это финтех (переводы) и соцсети (патреон, блогеры).

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

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

Доменная экспертиза важна для любых спецов: менеджеров, программистов, тестировщиков и сейлов. Если вы хотите однажды работать в гугле, то чтобы попасть, например, в команду Youtube, нужен опыт в видео и соцсетях. Вот такие компании будут плюсом в резюме: Megogo, MX player, Splice, Reddit, Vk.

Немного о том, из чего состоит доменная экспертиза на примере видео домена, в котором я работаю последние пару лет:
- знание технологий (WebRTC, h.264, CDN, Kurento)
- больших игроков (Netflix, RingCentral, Agora, BrightCove)
- значимых событий, в этой области (запуск Twitch в 2011, Apple отказывается от флэша и делает свой протокол HLS, создание кодека HEVC в 2013)
- стоимости продуктов или как она формируется (минуты подключения или другая форма трафика)
- бест практик по решению проблем
- что волнует клиентов и пользователей (качество подключения и переподключения, максимальное количество юзеров на лайв стрим).