Менеджер от боженьки

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

Менеджер от боженьки
Управление проектами
Подписаться
Когда мне предложили его написать, я подумал - зачем?

Курс менеджера от боженьки

Сегодня не обычная https://skillsetter.io/cohorts/project-manager

(дата старта следующего потока
- 17 августа)

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

Например, рисовать на чужом экране при скриншаринге, как в Slack или Miro.

Если отдать такую на оценку команде, скорее всего, разброс цифр будет космическим, потому что непонятно как ее делать. Один программист даст 40 часов, а другой скажет минимум месяц. Можно, конечно, взять самую большую цифру и закомититься на нее, но даже так есть большой риск не успеть.

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

Результатом такой задачи будет план разработки: дизайн (архитектура) фичи + разбивка на задачи. Конечно, никто не гарантирует закончить за 4-8 часов, это "для начала". Вполне может быть так, что после понадобится еще 2 дня, чтобы построить план.

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

Менеджер от боженьки
Управление проектами
Подписаться
Выясни кто стейкхолдер Был у меня один невероятно требовательный клиент - Сатиш.

Выясни кто стейкхолдер

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

По одной такой доработке переговоры зашли в тупик и под предлогом "сейчас придет мой босс и вас вообще размажет" к звонку присоединился Рави. Он был СЕО. Финальное решение подписывать с нами новый контракт или нет, было за ним.

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

И действительно, за пару имейлов мы все уладили и подписали контракт. Сатиша я просто ставил в копию для приличия, а он предпочитал не высовываться.

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

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

Менеджер от боженьки
Управление проектами
Подписаться
Баланс экспертизы в командеНа своей первой работе я думал:

Баланс экспертизы в команде

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

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

Например, на проекте умный собачий ошейник было много трудных задач, которые на стэковерлоу не нагуглишь. Надо было разбираться в специальном протоколе mqtt, договариваться с фирмварщиками как часто синхронизировать данные, и думать как считать шаги у собаки (у них необычное количество ног 🐕). Поэтому в команде работали 4 сеньора, 5 мидлов и всего 1 джун.

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

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

25% сеньоров, 50% мидлов, 25% джунов

Вот несколько причин почему он такой:

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

2️⃣ Больше всего задач с тэгом "обычные". Это продолжение уже существующего, хорошо знакомого команде функционала. Поэтому концентрация мидлов самая высокая.

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

4️⃣ Более скиловый сетап часто невыгоден компании. Если будут работать одни сеньоры, она просто не выйдет в плюс. Поэтому команды "разбавляют" менее опытными специалистами.

Менеджер от боженьки
Управление проектами
Подписаться
Грубая оценка[Заказчик]:

Грубая оценка

[Заказчик]:
- хочу вот такую фичу[Менеджер]:
- ок, мы оценим и завтра пришлем сколько будет стоить[З]:
- да, ок, а скажи хотя бы примерно сколько? какой порядок цифр?[Тимлид, пишет в личку]:
- по разработке там работы +- на неделю [М]:
- 100 часов, или $4,000, если грубо

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

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

общая оценка = оценка на разработку * 2,5

То есть, если на девелопмент нужно 40 часов, то вся фича целиком, от требований до поставки, будет стоить заказчику 40*2,5 = 100 часов. Дальше умножаем на средний рейт и получаем стоимость.

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

И вот откуда она берется:

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

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

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

1️⃣ обработать состояние, если еще не было транзакций;
2️⃣ запомнить последнюю выбранную дату в сортировке;
3️⃣ разные стили в списке транзакций у юр. лиц и физ. лиц;

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

С UX долгом такие же правила, как и с техническим. Его надо:

📌 легализовать
- объяснить бизнесу, почему он возникает и что будет, если на него забить.📌 отдавать
- в каждом спринте планировать немного времени на UX долг. Я обычно беру где-то 5%, т.е. 1-2 небольшие задачи.

Менеджер от боженьки
Управление проектами
Подписаться

Работа менеджера
- давать контекст

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

Цель нашей работы
- дать как можно больше информации о проекте, чтобы другие приняли правильное решение.

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

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

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

Менеджер от боженьки
Управление проектами
Подписаться
Записал небольшой вебинар про коммуникацию для менеджеров в iampm.

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

Посмотрите, тут интересно:

https://youtu.be/BrBf96RNn6s?t=120

Менеджер от боженьки
Управление проектами
Подписаться
Как не надо увольняться В моей команде работал рубист Костя.

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

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

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

Тут я охренел. Мы только что проговорили полчаса о всяких мелочах, и ты даже не упомянул, что хочешь уйти?? 🤨

Оказалось, что он уже нашел новую работу в каком-то беттинг-стартапе и договорился выйти к ним через 2 недели. 2 недели! Наш тогдашний беклог трещал от we-need-to-build-it-asap-фич, а на поиски толкового рубиста на рынке уходили месяцы. Для проекта это была большая проблема.

После долгих переговор мы договорились, что Костя отработает 3 недели, и еще 2 будет помогать на парт-тайме пару часов в день.

Не увольняйтесь как Костя. Это больно для команд, менеджеров и клиентов.

Ради приличия и душевного спокойствия Кости, имя тут ненастоящее :) Эта история смерджена из 2х реальных историй, которые когда-то произошли со мной.

Менеджер от боженьки
Управление проектами
Подписаться
Планирование релизов У зрелых команд есть релиз планирование.

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

Проходит оно так. Собираются бизнес и технари вместе и разговаривают:
1. Бизнес объясняет что надо поставить, чтобы ему было хорошо (= выпуск каких фич принесет максимальную пользу).
2. Технари объясняют какие задачи им удобнее (проще, легче, дешевле) поставить в ближайшее время.

На основе 1 и 2 договариваются о план релиза. Его записывают в джиру или ноушен, чтобы все были в курсе. Вот и все релиз планирование 😀

Хорошие практики:

1️⃣ Планировать на несколько релизов вперед, оптимально на 1-2 месяца. Если закладывать больше
- план будет неточным и постоянно меняться. Меньше
- сложно продавать. Здесь речь именно о точном плане с конкретными датами. Примерный план у нас уже есть
- это роудмап.

2️⃣ Постепенные релизы больших, рисковых изменений. Выкатываем новый код последовательно, начиная с небольшой части пользователей. Если у них все хорошо
- раскатываем на остальных. А если плохо, то пострадают хотя бы не все.

3️⃣ Релизить часто, но мало. При таком подходе сразу видно в каком месте проблема, ее легче локализовать, а следовательно, и починить. Ну и откатывать маленькие релизы проще.

На фото: великолепная фича Releases в джире

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

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

Такое письмо легко вычислить. Если текста больше, чем на лист А4, в нем есть эмоции или после прочтения хочется сказать "зачем я это прочитал?", значит, что-то не так.

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

- Проблема- Возможное решение (1)- Оптимальное решение (2)- Что будет, если забить- Когда надо принять решение

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

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

Для этого придумали кик офф встречу. В переводе с футбольного, это буквально ввод мяча с центра поля, значение слова сохранилось и в ИТ.

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

Вот что надо обсудить:1️⃣ Попросить заказчика еще раз проговорить цель проекта и свои ожидания. Тут нам и нужен сейл, чтобы все показания сошлись (скоуп, дедлайны).2️⃣ Представить команду. Рассказать кто за что отвечает.3️⃣ Рассказать о процессе разработки.4️⃣ Рассказать о роли заказчика в этом процессе, что от него ожидается. Обычно это аппрув требований и участие в демо. Сразу договариваемся о времени созвонов и высылаем на них инвайты.5️⃣ Спросить, кто будет бекапить закачика, если он недоступен, определить полномочия этого человека. Заказчики люди занятые, любят пропадать.6️⃣ Рассказать о планах первой итерации, т.е. что мы сделаем за 1 спринт.7️⃣ Рассказать о первой поставке, когда ожидается и что в нее войдет.8️⃣ Организационные штучки: таймзона, время доступности, каналы связи, отчеты, доступ в джиру, вот это все.

А дальше идем делать классный проект 😎.

Менеджер от боженьки
Управление проектами
Подписаться

Как следить за качеством (чек-лист)

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

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

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

Таких кусочков много, хватило на целый чек-лист:

https://telegra.ph/CHek-list-kachestva-proekta-03-29

Менеджер от боженьки
Управление проектами
Подписаться
Одно из самых сложных в работе для меня - давать негативный фидбек.

Как давать негативный фидбек

Одно из самых сложных в работе для меня
- давать негативный фидбек.

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

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

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

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

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


1. Стремись помочь. Критикуй с искренним желанием сделать мир лучше.
2. Предлагай конкретные шаги. Объясняй, что именно человек сделал не так, какой был негативный эффект и как его можно было избежать.
3. Будь благодарен за обратную связь. Когда слышишь негатив, твоя естественная реакция
- начать оправдываться и защищаться. Ее надо побороть и вспомнить про пункт
1.
4. Не всем советам обязательно следовать. Некоторые из них могу быть действительно "мимо". Только тебе решать к каким прислушаться.

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

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

Это не так!

В действительности у меня нет выбора получать их или нет. После регистрации они просто начинают приходить и все. Отписываться от новостей и скидок становится уже моей проблемой 😔

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

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

А вот эти вещи, наоборот, раздражают, лучше так не делать:❌ Чтобы отменить рассылку нужно залогиниться. ❌ Дополнительные шаги в момент отписки, типо "вы уверены, что хотите отписаться?"❌ Много чекбоксов для разных писем (скидки, новости и т.д.) и надо кликнуть на каждый. Нет кнопки "отписаться от всего". ❌ Пожалуй, самое грустное
- это бесполезные письма: "Нам сегодня 10 лет", "С Рождеством Христовым!" и тому подобные. В них для получателя нету никакой ценности.

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...