Что спрашивают на собеседованиях

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

От компании к компании вопросы часто повторяются, вот эти - самые популярные:

https://telegra.ph/Voprosy-na-PM-sobesedovaniyah-06-30

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

Удачи на интервью!

​"Новые правила деловой переписки"

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

Все это в ней есть, но в действительности книга о другом: о заботе, внимательности и уважении к читателю.

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

👉Как именно заботиться в переписке:

1️⃣ одно дело - одно сообщение, не надо обсуждать 3 проекта в 1 треде;
2️⃣ объяснять что внутри прикрепленных ссылок;
3️⃣ называть файлы так, чтобы их потом было легко найти на компьютере;
4️⃣ хвалить работу, достижения человека, а не его самого;
5️⃣ если накосячил, надо предлагать варианты решения проблемы, а не просто «прости, мне стыдно»

В тексте запросто теряются интонации и эмоции. Иногда даже смысл можно потерять по дороге. Поэтому главный совет выглядит вот так:

​Закрыть незавершенную задачу в спринте

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

Зависит от условий.

Посчитать сторю завершенной не будет проблемой, если:

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

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

​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. Если вам интересно какие продуктовые компании Минска попали в мой субъективный шорт-лист - напишите в лс. Публиковать его тут не совсем правильно.

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

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

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

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