Сколько зарабатывают и тратят аутсорсинговые компании
Иногда заходишь на работе на кухню и слышишь такой разговор:
Вот я гребу за 2К, а контора получает 40 баксов в час, это же почти 7К в месяц! Нехило так, 5К кладут себе в карман, могли бы и побольше платить.
Если пройти мимо такого дискуссии, ребята будут и дальше представлять себя героями картины "Бурлаки на Волге". Обсуждать чужие деньги, конечно, моветон, но раз уж об этом зашел разговор, расскажите им сколько на самом деле зарабатывает фирма.
Доходность в аутсорсинге - всего 10-15%. Это средние цифры по индустрии, где-то больше, где-то меньше. Кроме зарплаты, у компании есть еще много других затрат, смотрите:
💰 подоходный налог (13% в Беларуси) + ФСЗН (~170$) - 450$
💰 отпуск и больничный - 200$
💰 сейл отдел, который продал проект, заберет 5% от выручки - 350$
💰 зп других непродакшн сотрудников, за которых не платит заказчик - маркетологи, эйчары, директор (из расчета 0.5 непродакшн сотрудника на одного из продакшена) - $1000
💰 бенч, когда у человека нет проекта (минимум 10% времени в год) - 700$
💰 офис - 250$
💰 техника, печенье, корпоратив, страховка, компенсация спорта, курсы английского и прочие "мелочи" - 350$
💰 налог на прибыль или выручку (сильно зависит от страны, в которой компания получает деньги, пусть 3% от выручки) - 200$
В сумме получается $3,500 сверху зп (все расчеты, конечно, примерные), а значит компании остается $1,200 или 18% от того, что оплатил заказчик. Не так уж и много, как казалось на первый взгляд. А ведь это только постоянные издержки - деньги, которые надо платить, чтобы завтра не закрыться.
Чтобы не закрыться и послезавтра, компании вкладывают большую часть заработанного обратно в бизнес - открывают новые офисы, учебные центры, делают проекты в минус, чтобы заполучить выгодного клиента.
Времена, когда на аутсорсинге зарабатывали безумные деньги, остались в нулевых. Сейчас зарабатывают просто приличные 😎
Иногда заходишь на работе на кухню и слышишь такой разговор:
Вот я гребу за 2К, а контора получает 40 баксов в час, это же почти 7К в месяц! Нехило так, 5К кладут себе в карман, могли бы и побольше платить.
Если пройти мимо такого дискуссии, ребята будут и дальше представлять себя героями картины "Бурлаки на Волге". Обсуждать чужие деньги, конечно, моветон, но раз уж об этом зашел разговор, расскажите им сколько на самом деле зарабатывает фирма.
Доходность в аутсорсинге - всего 10-15%. Это средние цифры по индустрии, где-то больше, где-то меньше. Кроме зарплаты, у компании есть еще много других затрат, смотрите:
💰 подоходный налог (13% в Беларуси) + ФСЗН (~170$) - 450$
💰 отпуск и больничный - 200$
💰 сейл отдел, который продал проект, заберет 5% от выручки - 350$
💰 зп других непродакшн сотрудников, за которых не платит заказчик - маркетологи, эйчары, директор (из расчета 0.5 непродакшн сотрудника на одного из продакшена) - $1000
💰 бенч, когда у человека нет проекта (минимум 10% времени в год) - 700$
💰 офис - 250$
💰 техника, печенье, корпоратив, страховка, компенсация спорта, курсы английского и прочие "мелочи" - 350$
💰 налог на прибыль или выручку (сильно зависит от страны, в которой компания получает деньги, пусть 3% от выручки) - 200$
В сумме получается $3,500 сверху зп (все расчеты, конечно, примерные), а значит компании остается $1,200 или 18% от того, что оплатил заказчик. Не так уж и много, как казалось на первый взгляд. А ведь это только постоянные издержки - деньги, которые надо платить, чтобы завтра не закрыться.
Чтобы не закрыться и послезавтра, компании вкладывают большую часть заработанного обратно в бизнес - открывают новые офисы, учебные центры, делают проекты в минус, чтобы заполучить выгодного клиента.
Времена, когда на аутсорсинге зарабатывали безумные деньги, остались в нулевых. Сейчас зарабатывают просто приличные 😎
Фит по культуре
Один мой прошлый босс матерился. Иногда он делал презентацию, рисуя на доске жопу для иллюстрации какой-то мысли (иногда архитектуры). Мне было смешно и понятно, потому что я тоже иногда говорю жопа. Но в глазах некоторых менеджеров был ужас. Кто-то из них потом ушел из компании. Не из-за жопы конечно, но как-то не прижились, культурой не совпали.
Когда нанимаешь человека на работу, важно смотреть, чтобы он подошел еще и по культуре. Иначе всё рабочее время будет тратиться не на решение задач, а на выравнивание по ценностям.
Думаю, если бы мы тогда писали в вакансиях "у нас иногда ругаются матом", это бросалось бы в глаза, зато часть людей просто не отправила бы резюме. Такая честность выгодна всем: кандидатам понятно куда они устраиваются на работу и что их ждет, а компания экономит время более точечным отсевом.
Круто, когда компания транслирует наружу свои ожидания и культуру. Вот несколько таких примеров:
- Культурный код Pandadoc
- Amazon leadership principles
- Советы для кандидатов в Яндекс
Один мой прошлый босс матерился. Иногда он делал презентацию, рисуя на доске жопу для иллюстрации какой-то мысли (иногда архитектуры). Мне было смешно и понятно, потому что я тоже иногда говорю жопа. Но в глазах некоторых менеджеров был ужас. Кто-то из них потом ушел из компании. Не из-за жопы конечно, но как-то не прижились, культурой не совпали.
Когда нанимаешь человека на работу, важно смотреть, чтобы он подошел еще и по культуре. Иначе всё рабочее время будет тратиться не на решение задач, а на выравнивание по ценностям.
Думаю, если бы мы тогда писали в вакансиях "у нас иногда ругаются матом", это бросалось бы в глаза, зато часть людей просто не отправила бы резюме. Такая честность выгодна всем: кандидатам понятно куда они устраиваются на работу и что их ждет, а компания экономит время более точечным отсевом.
Круто, когда компания транслирует наружу свои ожидания и культуру. Вот несколько таких примеров:
- Культурный код Pandadoc
- Amazon leadership principles
- Советы для кандидатов в Яндекс
Привет!
Это канал про управление проектами. Тут про команды, заказчиков, разработку, процессы и карьеру в ПМ.
Посты выходят раз в неделю, иногда бывает реклама.
Оставляйте комменты, если вам понравилась какая-то мысль или наоборот, считаете что написана полная чепуха. Благодаря этому канал растет, а я радуюсь и пишу больше.
Про автора:
Канал веду я, Рома Ковалевский, чтобы было нескучно жить и потому что люблю работу, хочется про нее рассказывать.
Сейчас работаю Senior Technical Program Manager в берлинской фудтех компании HelloFresh. Раньше я делал SDK а-ля Tiktok, умный собачий ошейник и детектор списывания на экзаменах, из крупых проектов.
Еще я веду сообщество менеджеров ПМ совет. Раз в неделю в зуме мы обсуждаем рабочие ситуации и кейсы из реальной жизни. Например, что делать, если команда фейлит дедлайны или как находить баги рано.
Несколько выступлений:
- Митап про маст хэв плагины в джире
- Вебинар про коммуникацию с командой и закачиком
Делаю консультации по поиску работы в Европе, настройке процессов и решению проблем в разработке, найму ПМов ($80/час).
Добавляйтесь в линкедин профиль, будем там дружить 👋. Или пишите в личку @romkovalevsky.
А вы?
Это канал про управление проектами. Тут про команды, заказчиков, разработку, процессы и карьеру в ПМ.
Посты выходят раз в неделю, иногда бывает реклама.
Оставляйте комменты, если вам понравилась какая-то мысль или наоборот, считаете что написана полная чепуха. Благодаря этому канал растет, а я радуюсь и пишу больше.
Про автора:
Канал веду я, Рома Ковалевский, чтобы было нескучно жить и потому что люблю работу, хочется про нее рассказывать.
Сейчас работаю Senior Technical Program Manager в берлинской фудтех компании HelloFresh. Раньше я делал SDK а-ля Tiktok, умный собачий ошейник и детектор списывания на экзаменах, из крупых проектов.
Еще я веду сообщество менеджеров ПМ совет. Раз в неделю в зуме мы обсуждаем рабочие ситуации и кейсы из реальной жизни. Например, что делать, если команда фейлит дедлайны или как находить баги рано.
Несколько выступлений:
- Митап про маст хэв плагины в джире
- Вебинар про коммуникацию с командой и закачиком
Делаю консультации по поиску работы в Европе, настройке процессов и решению проблем в разработке, найму ПМов ($80/час).
Добавляйтесь в линкедин профиль, будем там дружить 👋. Или пишите в личку @romkovalevsky.
А вы?
Пример оценки фичи
Представьте, что ведете проект а-ля мессенджер. Заказчик присылает вам такое письмо:
Хочу фичу, чтобы можно было отправлять фото в чат. Сколько будет стоить?
Давайте разберем, что делать.
Если на проекте есть бизнес-аналитик, просим его расписать юзкейсы. Если нет - пишем сами, примерно так:
📌 получить доступ к галерее;
📌 выбрать фото + превью перед отправкой;
📌 загрузить фото в чат;
📌 посмотреть отправленное фото;
Берем эти юзкейсы и идем утверждать их с заказчиком. Там же обговариваем другие кейсы, которые можно придумать для этой фичи - отправка видео, сжатие, история, редактирование перед отправкой и т.п. Чем больше насобираем сейчас, тем меньше шанс услышать на приемке "ой, а где сжатие? я думал, это подразумевается...".
Чтобы не раздувать скоуп, предлагаем все необязательные кейсы сделать потом, в фазе 2. Вдруг фича вообще не пойдет? На этом этапе полезно смотреть, как аналогичные фичи работают у конкурентов 👀.
Когда кейсы утверждены, идем к команде оценивать. Собираем всех в зуме и рассказываем про фичу.
Мобильщики смотрят на требования и говорят, что на разработку нужно 80 часов. Бекенд просит 40. Дизайнеру понадобится 40 на отрисовку экранов. В сумме 160.
Закладываем 30% на тестирование, 20% на стабилизацию, 10% на коммуникации + 10% на себя. Сверху накидываем 10% рисков и получаем 140 часов.
По рейту 40 в час выходит $12,000. Но это еще не все.
Фотографии нужно где-то хранить, для этого понадобится отдельный сервер. Заказчик говорит, что фичей будет пользоваться каждый пятый юзер, загружая где-то 100МБ фоток в месяц. Берем текущий МАУ, приносим бекендеру и получаем какую-то цифру, например, $500 в месяц.
Напоследок, прикинем таймлайн 📅.
Бекенд может начать первым, параллельно будем рисовать дизайн. По оценке команды это неделя, но добавим 3 дня на обсуждения, утверждение макетов и риски.
Мобильщики просили 2 недели, но с тестированием и стабилизацией, разработка займет все три. После первой недели обязательно сделаем демо, чтобы избежать сюрпризов перед релизом. Закладываем день на поставку и еще 2 на риски.
В итоге получаем 5 недель.
Оценка готова. Ставим в копию сейла и отправляем заказчику.
Представьте, что ведете проект а-ля мессенджер. Заказчик присылает вам такое письмо:
Хочу фичу, чтобы можно было отправлять фото в чат. Сколько будет стоить?
Давайте разберем, что делать.
Если на проекте есть бизнес-аналитик, просим его расписать юзкейсы. Если нет - пишем сами, примерно так:
📌 получить доступ к галерее;
📌 выбрать фото + превью перед отправкой;
📌 загрузить фото в чат;
📌 посмотреть отправленное фото;
Берем эти юзкейсы и идем утверждать их с заказчиком. Там же обговариваем другие кейсы, которые можно придумать для этой фичи - отправка видео, сжатие, история, редактирование перед отправкой и т.п. Чем больше насобираем сейчас, тем меньше шанс услышать на приемке "ой, а где сжатие? я думал, это подразумевается...".
Чтобы не раздувать скоуп, предлагаем все необязательные кейсы сделать потом, в фазе 2. Вдруг фича вообще не пойдет? На этом этапе полезно смотреть, как аналогичные фичи работают у конкурентов 👀.
Когда кейсы утверждены, идем к команде оценивать. Собираем всех в зуме и рассказываем про фичу.
Мобильщики смотрят на требования и говорят, что на разработку нужно 80 часов. Бекенд просит 40. Дизайнеру понадобится 40 на отрисовку экранов. В сумме 160.
Закладываем 30% на тестирование, 20% на стабилизацию, 10% на коммуникации + 10% на себя. Сверху накидываем 10% рисков и получаем 140 часов.
По рейту 40 в час выходит $12,000. Но это еще не все.
Фотографии нужно где-то хранить, для этого понадобится отдельный сервер. Заказчик говорит, что фичей будет пользоваться каждый пятый юзер, загружая где-то 100МБ фоток в месяц. Берем текущий МАУ, приносим бекендеру и получаем какую-то цифру, например, $500 в месяц.
Напоследок, прикинем таймлайн 📅.
Бекенд может начать первым, параллельно будем рисовать дизайн. По оценке команды это неделя, но добавим 3 дня на обсуждения, утверждение макетов и риски.
Мобильщики просили 2 недели, но с тестированием и стабилизацией, разработка займет все три. После первой недели обязательно сделаем демо, чтобы избежать сюрпризов перед релизом. Закладываем день на поставку и еще 2 на риски.
В итоге получаем 5 недель.
Оценка готова. Ставим в копию сейла и отправляем заказчику.
6 книг для начинающего менеджера
Если ваш друг хочет стать менеджером и спрашивает, что ему почитать, посоветуйте вот эти книги:
1️⃣ Как стать менеджером в ИТ - из чего состоит профессия.
2️⃣ Черная книга менеджера - как работает ИТ бизнес, с точки зрения его владельца.
3️⃣ Scrum и XP, заметки с передовой - как пользоваться скрамом.
4️⃣ Как пасти котов - как ставить задачи разработчикам и помогать им расти.
5️⃣ Не заставляйте меня думать - как делать удобные интерфейсы, чтобы было понятно и бумеру и зумеру.
6️⃣ Разработка требований ПО - как из фичи на месяц сделать фичу на неделю с помощью требований.
Книжки все короткие (кроме последней) и несложные, чтобы начинающий менеджер не впал в тоску и не передумал. Для начала самое то.
И, конечно, советуйте этот канал 😊
Если ваш друг хочет стать менеджером и спрашивает, что ему почитать, посоветуйте вот эти книги:
1️⃣ Как стать менеджером в ИТ - из чего состоит профессия.
2️⃣ Черная книга менеджера - как работает ИТ бизнес, с точки зрения его владельца.
3️⃣ Scrum и XP, заметки с передовой - как пользоваться скрамом.
4️⃣ Как пасти котов - как ставить задачи разработчикам и помогать им расти.
5️⃣ Не заставляйте меня думать - как делать удобные интерфейсы, чтобы было понятно и бумеру и зумеру.
6️⃣ Разработка требований ПО - как из фичи на месяц сделать фичу на неделю с помощью требований.
Книжки все короткие (кроме последней) и несложные, чтобы начинающий менеджер не впал в тоску и не передумал. Для начала самое то.
И, конечно, советуйте этот канал 😊
Длительность спринта
Когда стартуешь новый проект, нужно договориться какой будет длина спринта. Ее редко меняют по ходу проекта, поэтому решение, поистине, историческое.
Сколько же выбрать? Скрам предлагает любой срок, вплоть до 1 месяца. Советуют все же сильно не затягивать, чтобы как можно чаще показывать пользователям новые фичи и получать фидбек.
Обычно спринты делают кратным неделе, чтобы начинать и заканчивать в один и тот же день. Получаются такие варианты:
- 1 неделя;
- 2 недели;
- 3 недели;
- 4 недели;
Выбирая длительность, опирайтесь на количество шагов в definition of done. Чем их меньше, тем быстрее команда может выпускать задачи, и тем меньшая длина спринта нужна.
Например, у меня сейчас мобильный проект без бекенда, поэтому наш спринт всего 7 дней.
А в проектах, где есть бекенд и фронтенд обычно выбирают 2 недели. Это самый популярный вариант, который вы найдете у двух команд из трех. Столько достаточно, чтобы успеть выпустить значимое обновление, и одновременно не скатиться в вотерфолл.
Когда стартуешь новый проект, нужно договориться какой будет длина спринта. Ее редко меняют по ходу проекта, поэтому решение, поистине, историческое.
Сколько же выбрать? Скрам предлагает любой срок, вплоть до 1 месяца. Советуют все же сильно не затягивать, чтобы как можно чаще показывать пользователям новые фичи и получать фидбек.
Обычно спринты делают кратным неделе, чтобы начинать и заканчивать в один и тот же день. Получаются такие варианты:
- 1 неделя;
- 2 недели;
- 3 недели;
- 4 недели;
Выбирая длительность, опирайтесь на количество шагов в definition of done. Чем их меньше, тем быстрее команда может выпускать задачи, и тем меньшая длина спринта нужна.
Например, у меня сейчас мобильный проект без бекенда, поэтому наш спринт всего 7 дней.
А в проектах, где есть бекенд и фронтенд обычно выбирают 2 недели. Это самый популярный вариант, который вы найдете у двух команд из трех. Столько достаточно, чтобы успеть выпустить значимое обновление, и одновременно не скатиться в вотерфолл.
Как фильтровать идеи клиента
Иногда заказчики просят сделать что-то, что кажется нам странным. С одной стороны, они знают лучше, что сработает в их бизнесе, на то они и заказчики. С другой, добавить музыку на сайт или выпустить месячную фичу за неделю, серьезно?
1️⃣ Вот как вежливо не согласиться:
- I'm not really sure about that.
- The team's got few concerns about this feature.
- I can't see how it benefits the product.
2️⃣ Затем добавляем аргументов:
- Have you seen such a solution somewhere on the market?
- Have you done any user research on that? How will it affect the product?
- The estimate of this feature is 1 month. We can reduce it to 3 weeks by...., but not more.
- Making it this way will bring some negative impact: ...
3️⃣ В конце немного сглаживаем углы:
- Anyway, the final decision is on you.
- These are just my thoughts, you know your product better.
- I just want to show you the alternatives, so that you have a full picture.
Иногда заказчики просят сделать что-то, что кажется нам странным. С одной стороны, они знают лучше, что сработает в их бизнесе, на то они и заказчики. С другой, добавить музыку на сайт или выпустить месячную фичу за неделю, серьезно?
1️⃣ Вот как вежливо не согласиться:
- I'm not really sure about that.
- The team's got few concerns about this feature.
- I can't see how it benefits the product.
2️⃣ Затем добавляем аргументов:
- Have you seen such a solution somewhere on the market?
- Have you done any user research on that? How will it affect the product?
- The estimate of this feature is 1 month. We can reduce it to 3 weeks by...., but not more.
- Making it this way will bring some negative impact: ...
3️⃣ В конце немного сглаживаем углы:
- Anyway, the final decision is on you.
- These are just my thoughts, you know your product better.
- I just want to show you the alternatives, so that you have a full picture.
Почтовый спам при регистрации
В интернете есть одна вещь, которую я не понимаю. Почему-то все сервисы думают, что я хочу получать от них рекламные письма, после того как зарегистрировался.
Это не так!
В действительности у меня нет выбора получать их или нет. После регистрации они просто начинают приходить и все. Отписываться от новостей и скидок становится уже моей проблемой 😔
Так происходит потому, что менеджеры и маркетологи во что бы то ни стало хотят продвинуть свой товар. Их можно понять, за наше с вами внимание борются тысячи бизнесов. Но когда продвижение слишком навязчиво, получается все наоборот - пользователи не покупают, а злятся.
Вот несколько штук, которые уменьшат раздражение у ворчунов вроде меня:
✅ Поставить чек-бокс "получать рекламные письма" при регистрации. Сделать его невыбранным по дефолту.
✅ В каждом письме добавлять ссылку "отписаться" внизу. Она заметная, на нее легко нажать.
✅ При переходе по ней должно быть максимум одно действие, чтобы отписаться.
А вот эти вещи, наоборот, раздражают, лучше так не делать:
❌ Чтобы отменить рассылку нужно залогиниться.
❌ Дополнительные шаги в момент отписки, типо "вы уверены, что хотите отписаться?"
❌ Много чекбоксов для разных писем (скидки, новости и т.д.) и надо кликнуть на каждый. Нет кнопки "отписаться от всего".
❌ Пожалуй, самое грустное - это бесполезные письма: "Нам сегодня 10 лет", "С Рождеством Христовым!" и тому подобные. В них для получателя нету никакой ценности.
В интернете есть одна вещь, которую я не понимаю. Почему-то все сервисы думают, что я хочу получать от них рекламные письма, после того как зарегистрировался.
Это не так!
В действительности у меня нет выбора получать их или нет. После регистрации они просто начинают приходить и все. Отписываться от новостей и скидок становится уже моей проблемой 😔
Так происходит потому, что менеджеры и маркетологи во что бы то ни стало хотят продвинуть свой товар. Их можно понять, за наше с вами внимание борются тысячи бизнесов. Но когда продвижение слишком навязчиво, получается все наоборот - пользователи не покупают, а злятся.
Вот несколько штук, которые уменьшат раздражение у ворчунов вроде меня:
✅ Поставить чек-бокс "получать рекламные письма" при регистрации. Сделать его невыбранным по дефолту.
✅ В каждом письме добавлять ссылку "отписаться" внизу. Она заметная, на нее легко нажать.
✅ При переходе по ней должно быть максимум одно действие, чтобы отписаться.
А вот эти вещи, наоборот, раздражают, лучше так не делать:
❌ Чтобы отменить рассылку нужно залогиниться.
❌ Дополнительные шаги в момент отписки, типо "вы уверены, что хотите отписаться?"
❌ Много чекбоксов для разных писем (скидки, новости и т.д.) и надо кликнуть на каждый. Нет кнопки "отписаться от всего".
❌ Пожалуй, самое грустное - это бесполезные письма: "Нам сегодня 10 лет", "С Рождеством Христовым!" и тому подобные. В них для получателя нету никакой ценности.
Как давать негативный фидбек
Одно из самых сложных в работе для меня - давать негативный фидбек.
С позитивным все легко и просто, ведь хвалить людей всегда приятно. А критиковать как-то неуютно, таких разговоров хочется избежать. Мол, откуда вообще у меня право говорить человеку как ему жить?
Обычно фидбек дают на встречах 1-1. Чтобы сотрудник прислушался, надо доносить проблему максимально точно: ты не вложился в оценку -> поехали сроки -> заказчик недоволен. Если говорить общими фразами и полунамеками, есть большой шанс, что тебя не услышат.
С другой стороны, важно не задеть чувства человека. Чтобы ему не показалось, что его отчитывают как школьника за невыполненную домашку 🤓.
Есть разные техники, которые помогают справиться с этим балансом, например, бутерброд или BOFF.
Мне понравились принципы, которые использует Нетфликс, потому что они короткие и простые. Всего 2 совета для тех, кто дает фидбек и 2 для принимающей стороны:
1. Стремись помочь. Критикуй с искренним желанием сделать мир лучше.
2. Предлагай конкретные шаги. Объясняй, что именно человек сделал не так, какой был негативный эффект и как его можно было избежать.
3. Будь благодарен за обратную связь. Когда слышишь негатив, твоя естественная реакция - начать оправдываться и защищаться. Ее надо побороть и вспомнить про пункт 1.
4. Не всем советам обязательно следовать. Некоторые из них могу быть действительно "мимо". Только тебе решать к каким прислушаться.
Одно из самых сложных в работе для меня - давать негативный фидбек.
С позитивным все легко и просто, ведь хвалить людей всегда приятно. А критиковать как-то неуютно, таких разговоров хочется избежать. Мол, откуда вообще у меня право говорить человеку как ему жить?
Обычно фидбек дают на встречах 1-1. Чтобы сотрудник прислушался, надо доносить проблему максимально точно: ты не вложился в оценку -> поехали сроки -> заказчик недоволен. Если говорить общими фразами и полунамеками, есть большой шанс, что тебя не услышат.
С другой стороны, важно не задеть чувства человека. Чтобы ему не показалось, что его отчитывают как школьника за невыполненную домашку 🤓.
Есть разные техники, которые помогают справиться с этим балансом, например, бутерброд или BOFF.
Мне понравились принципы, которые использует Нетфликс, потому что они короткие и простые. Всего 2 совета для тех, кто дает фидбек и 2 для принимающей стороны:
1. Стремись помочь. Критикуй с искренним желанием сделать мир лучше.
2. Предлагай конкретные шаги. Объясняй, что именно человек сделал не так, какой был негативный эффект и как его можно было избежать.
3. Будь благодарен за обратную связь. Когда слышишь негатив, твоя естественная реакция - начать оправдываться и защищаться. Ее надо побороть и вспомнить про пункт 1.
4. Не всем советам обязательно следовать. Некоторые из них могу быть действительно "мимо". Только тебе решать к каким прислушаться.
Как следить за качеством (чек-лист)
Представьте, что приходите на новый проект и начинаете его изучать. Что досталось вам в наследство?
Можно пойти по классическому пути и исследовать проектный треугольник. Довольно просто вы узнаете, как обстоят дела со сроками, бюджетом и стоимостью. Для этого достаточно поговорить с прошлым менеджером или тимлидом.
Но как понять, что с качеством? Простого ответа тут не будет, потому что качество нельзя измерить одной цифрой и сказать вот тут низкое, а тут высокое. Вместо этого можно поисследовать разные кусочки проекта, которые в итоге на него влияют.
Таких кусочков много, хватило на целый чек-лист:
https://telegra.ph/CHek-list-kachestva-proekta-03-29
Представьте, что приходите на новый проект и начинаете его изучать. Что досталось вам в наследство?
Можно пойти по классическому пути и исследовать проектный треугольник. Довольно просто вы узнаете, как обстоят дела со сроками, бюджетом и стоимостью. Для этого достаточно поговорить с прошлым менеджером или тимлидом.
Но как понять, что с качеством? Простого ответа тут не будет, потому что качество нельзя измерить одной цифрой и сказать вот тут низкое, а тут высокое. Вместо этого можно поисследовать разные кусочки проекта, которые в итоге на него влияют.
Таких кусочков много, хватило на целый чек-лист:
https://telegra.ph/CHek-list-kachestva-proekta-03-29
Кик офф
Когда стартуешь новый проект, всем нужен какой-то условный знак, мол, "начинаем". Для этого придумали кик офф встречу. В переводе с футбольного, это буквально ввод мяча с центра поля, значение слова сохранилось и в ИТ.
Кик офф проводит менеджер, приглашая заказчика, его команду, свою команду и сейла, который заключил договор.
Вот что надо обсудить:
1️⃣ Попросить заказчика еще раз проговорить цель проекта и свои ожидания. Тут нам и нужен сейл, чтобы все показания сошлись (скоуп, дедлайны).
2️⃣ Представить команду. Рассказать кто за что отвечает.
3️⃣ Рассказать о процессе разработки.
4️⃣ Рассказать о роли заказчика в этом процессе, что от него ожидается. Обычно это аппрув требований и участие в демо. Сразу договариваемся о времени созвонов и высылаем на них инвайты.
5️⃣ Спросить, кто будет бекапить закачика, если он недоступен, определить полномочия этого человека. Заказчики люди занятые, любят пропадать.
6️⃣ Рассказать о планах первой итерации, т.е. что мы сделаем за 1 спринт.
7️⃣ Рассказать о первой поставке, когда ожидается и что в нее войдет.
8️⃣ Организационные штучки: таймзона, время доступности, каналы связи, отчеты, доступ в джиру, вот это все.
А дальше идем делать классный проект 😎.
Когда стартуешь новый проект, всем нужен какой-то условный знак, мол, "начинаем". Для этого придумали кик офф встречу. В переводе с футбольного, это буквально ввод мяча с центра поля, значение слова сохранилось и в ИТ.
Кик офф проводит менеджер, приглашая заказчика, его команду, свою команду и сейла, который заключил договор.
Вот что надо обсудить:
1️⃣ Попросить заказчика еще раз проговорить цель проекта и свои ожидания. Тут нам и нужен сейл, чтобы все показания сошлись (скоуп, дедлайны).
2️⃣ Представить команду. Рассказать кто за что отвечает.
3️⃣ Рассказать о процессе разработки.
4️⃣ Рассказать о роли заказчика в этом процессе, что от него ожидается. Обычно это аппрув требований и участие в демо. Сразу договариваемся о времени созвонов и высылаем на них инвайты.
5️⃣ Спросить, кто будет бекапить закачика, если он недоступен, определить полномочия этого человека. Заказчики люди занятые, любят пропадать.
6️⃣ Рассказать о планах первой итерации, т.е. что мы сделаем за 1 спринт.
7️⃣ Рассказать о первой поставке, когда ожидается и что в нее войдет.
8️⃣ Организационные штучки: таймзона, время доступности, каналы связи, отчеты, доступ в джиру, вот это все.
А дальше идем делать классный проект 😎.
Удобные письма
Некоторые письма только откроешь и сразу хочется закрыть. "Ой, тут что-то непонятное, разберусь с этим потом". И откладываешь в долгий ящик.
Такое письмо легко вычислить. Если текста больше, чем на лист А4, в нем есть эмоции или после прочтения хочется сказать "зачем я это прочитал?", значит, что-то не так.
Чтобы на ваши письма отвечали быстро, старайтесь экономить время читателя и предугадывать его вопросы по ходу текста. Например, используя вот такую структуру:
- Проблема
- Возможное решение (1)
- Оптимальное решение (2)
- Что будет, если забить
- Когда надо принять решение
Человек, который получит такое письмо, сможет ответить на него всего одним символом - "1". Одна цифра и вопрос решен, класс же! При этом читатель потратил минимум своего времени, и будет вам за это благодарен.
Некоторые письма только откроешь и сразу хочется закрыть. "Ой, тут что-то непонятное, разберусь с этим потом". И откладываешь в долгий ящик.
Такое письмо легко вычислить. Если текста больше, чем на лист А4, в нем есть эмоции или после прочтения хочется сказать "зачем я это прочитал?", значит, что-то не так.
Чтобы на ваши письма отвечали быстро, старайтесь экономить время читателя и предугадывать его вопросы по ходу текста. Например, используя вот такую структуру:
- Проблема
- Возможное решение (1)
- Оптимальное решение (2)
- Что будет, если забить
- Когда надо принять решение
Человек, который получит такое письмо, сможет ответить на него всего одним символом - "1". Одна цифра и вопрос решен, класс же! При этом читатель потратил минимум своего времени, и будет вам за это благодарен.
Планирование релизов
У зрелых команд есть релиз планирование. Его делают, чтобы определить какие фичи когда выпускать. Эта инфа нужна как сейлам, чтобы давать обещания клиентам, так и команде, чтобы правильно организовать разработку.
Проходит оно так. Собираются бизнес и технари вместе и разговаривают:
1. Бизнес объясняет что надо поставить, чтобы ему было хорошо (= выпуск каких фич принесет максимальную пользу).
2. Технари объясняют какие задачи им удобнее (проще, легче, дешевле) поставить в ближайшее время.
На основе 1 и 2 договариваются о план релиза. Его записывают в джиру или ноушен, чтобы все были в курсе. Вот и все релиз планирование 😀
Хорошие практики:
1️⃣ Планировать на несколько релизов вперед, оптимально на 1-2 месяца. Если закладывать больше - план будет неточным и постоянно меняться. Меньше - сложно продавать. Здесь речь именно о точном плане с конкретными датами. Примерный план у нас уже есть - это роудмап.
2️⃣ Постепенные релизы больших, рисковых изменений. Выкатываем новый код последовательно, начиная с небольшой части пользователей. Если у них все хорошо - раскатываем на остальных. А если плохо, то пострадают хотя бы не все.
3️⃣ Релизить часто, но мало. При таком подходе сразу видно в каком месте проблема, ее легче локализовать, а следовательно, и починить. Ну и откатывать маленькие релизы проще.
На фото: великолепная фича Releases в джире
У зрелых команд есть релиз планирование. Его делают, чтобы определить какие фичи когда выпускать. Эта инфа нужна как сейлам, чтобы давать обещания клиентам, так и команде, чтобы правильно организовать разработку.
Проходит оно так. Собираются бизнес и технари вместе и разговаривают:
1. Бизнес объясняет что надо поставить, чтобы ему было хорошо (= выпуск каких фич принесет максимальную пользу).
2. Технари объясняют какие задачи им удобнее (проще, легче, дешевле) поставить в ближайшее время.
На основе 1 и 2 договариваются о план релиза. Его записывают в джиру или ноушен, чтобы все были в курсе. Вот и все релиз планирование 😀
Хорошие практики:
1️⃣ Планировать на несколько релизов вперед, оптимально на 1-2 месяца. Если закладывать больше - план будет неточным и постоянно меняться. Меньше - сложно продавать. Здесь речь именно о точном плане с конкретными датами. Примерный план у нас уже есть - это роудмап.
2️⃣ Постепенные релизы больших, рисковых изменений. Выкатываем новый код последовательно, начиная с небольшой части пользователей. Если у них все хорошо - раскатываем на остальных. А если плохо, то пострадают хотя бы не все.
3️⃣ Релизить часто, но мало. При таком подходе сразу видно в каком месте проблема, ее легче локализовать, а следовательно, и починить. Ну и откатывать маленькие релизы проще.
На фото: великолепная фича Releases в джире
Как не надо увольняться
В моей команде работал рубист Костя. Он был крепким мидлом, умел писать хороший код. Костя был скромным парнем, не ленился, но и в бой особо не рвался. Он спокойно делал свои таски и в 6 вечера шел домой. Меня устраивала работа с ним, такие руки всегда нужны на проекте.
Мы проводили встречи 1-1 каждые пару месяцев, чтобы обсудить как идут дела, дать друг другу фидбек. На одной такой встрече все шло как обычно: "Особых проблем на проекте не вижу, с командой комфортно" и т.д. и т.п.
Встреча уже подходила к концу, я подводил итог, что мы за сегодня обсудили и скорее в шутку сказал: "Все в порядке, работаем дальше, увольняться пока не собираешься". Костя заулыбался и говорит "Ну, вообще-то, собираюсь".
Тут я охренел. Мы только что проговорили полчаса о всяких мелочах, и ты даже не упомянул, что хочешь уйти?? 🤨
Оказалось, что он уже нашел новую работу в каком-то беттинг-стартапе и договорился выйти к ним через 2 недели. 2 недели! Наш тогдашний беклог трещал от we-need-to-build-it-asap-фич, а на поиски толкового рубиста на рынке уходили месяцы. Для проекта это была большая проблема.
После долгих переговор мы договорились, что Костя отработает 3 недели, и еще 2 будет помогать на парт-тайме пару часов в день.
Не увольняйтесь как Костя. Это больно для команд, менеджеров и клиентов.
Ради приличия и душевного спокойствия Кости, имя тут ненастоящее :) Эта история смерджена из 2х реальных историй, которые когда-то произошли со мной.
В моей команде работал рубист Костя. Он был крепким мидлом, умел писать хороший код. Костя был скромным парнем, не ленился, но и в бой особо не рвался. Он спокойно делал свои таски и в 6 вечера шел домой. Меня устраивала работа с ним, такие руки всегда нужны на проекте.
Мы проводили встречи 1-1 каждые пару месяцев, чтобы обсудить как идут дела, дать друг другу фидбек. На одной такой встрече все шло как обычно: "Особых проблем на проекте не вижу, с командой комфортно" и т.д. и т.п.
Встреча уже подходила к концу, я подводил итог, что мы за сегодня обсудили и скорее в шутку сказал: "Все в порядке, работаем дальше, увольняться пока не собираешься". Костя заулыбался и говорит "Ну, вообще-то, собираюсь".
Тут я охренел. Мы только что проговорили полчаса о всяких мелочах, и ты даже не упомянул, что хочешь уйти?? 🤨
Оказалось, что он уже нашел новую работу в каком-то беттинг-стартапе и договорился выйти к ним через 2 недели. 2 недели! Наш тогдашний беклог трещал от we-need-to-build-it-asap-фич, а на поиски толкового рубиста на рынке уходили месяцы. Для проекта это была большая проблема.
После долгих переговор мы договорились, что Костя отработает 3 недели, и еще 2 будет помогать на парт-тайме пару часов в день.
Не увольняйтесь как Костя. Это больно для команд, менеджеров и клиентов.
Ради приличия и душевного спокойствия Кости, имя тут ненастоящее :) Эта история смерджена из 2х реальных историй, которые когда-то произошли со мной.
Записал небольшой вебинар про коммуникацию для менеджеров в iampm.club. Рассказываю
- как общаться с заказчиком, чтобы он тебя зауважал;
- какими словами можно задеть американца;
- что делать, чтобы стать любимчиком босса;
Посмотрите, тут интересно:
https://youtu.be/BrBf96RNn6s?t=120
- как общаться с заказчиком, чтобы он тебя зауважал;
- какими словами можно задеть американца;
- что делать, чтобы стать любимчиком босса;
Посмотрите, тут интересно:
https://youtu.be/BrBf96RNn6s?t=120
YouTube
Бонусная лекция: "Как общаться с заказчиком и не наломать дров" 3
Работа менеджера - давать контекст
Программисты пишут код, тестировщики его проверяют, дизайнеры рисуют интерфейсы, а что полезного делают менеджеры? Дают контекст.
Цель нашей работы - дать как можно больше информации о проекте, чтобы другие приняли правильное решение.
Например, можно рассказывать разработчикам как устроен бизнес. Как платят клиенты, что их больше всего интересует, какая у компании ближайшая цель. Благодаря этим знаниям программисту будет очевидно, что вот на это письмо клиента надо очень быстро ответить, а вот тот баг может подождать. И он в моменте примет оптимальное решение.
Или в обратную сторону - рассказывать бизнесу про разработку. Какие у нас сейчас проблемы, на что они влияют, какие фичи будет сделать очень сложно, а какие щелкнем как орешки. Благодаря этим знаниям бизнес сможет давать более точные обещания клиентам и выглядеть экспертно.
Менеджер - это такой мостик между разработкой и бизнесом, задача которого сблизить и подружить эти две вселенные.
Программисты пишут код, тестировщики его проверяют, дизайнеры рисуют интерфейсы, а что полезного делают менеджеры? Дают контекст.
Цель нашей работы - дать как можно больше информации о проекте, чтобы другие приняли правильное решение.
Например, можно рассказывать разработчикам как устроен бизнес. Как платят клиенты, что их больше всего интересует, какая у компании ближайшая цель. Благодаря этим знаниям программисту будет очевидно, что вот на это письмо клиента надо очень быстро ответить, а вот тот баг может подождать. И он в моменте примет оптимальное решение.
Или в обратную сторону - рассказывать бизнесу про разработку. Какие у нас сейчас проблемы, на что они влияют, какие фичи будет сделать очень сложно, а какие щелкнем как орешки. Благодаря этим знаниям бизнес сможет давать более точные обещания клиентам и выглядеть экспертно.
Менеджер - это такой мостик между разработкой и бизнесом, задача которого сблизить и подружить эти две вселенные.
UX долги
Все знают про технический долг, попривыкли к этому понятию. Если бизнес занимает у разработки немного качества, чтобы сделать фичу супер быстро, то надо сразу планировать доработки и не тянуть с возвратом долга. В противном случае проекту плохеет: новые фичи занимают все больше времени, постоянные баги в продакшене, лица программистов становятся грустнее с каждым релизом 😔.
А бывает еще UX долг. Это аналогичная штука, только про интерфейс. Например, мы делаем экран транзакций в мобильном банке и решаем отложить вот эти задачи, чтобы поскорее выпустить фичу:
1️⃣ обработать состояние, если еще не было транзакций;
2️⃣ запомнить последнюю выбранную дату в сортировке;
3️⃣ разные стили в списке транзакций у юр. лиц и физ. лиц;
Действительно, без них можно жить какое-то время и даже пользоваться приложением. Но в 2021 люди привыкли к вылизанным интерфейсам в духе эппл мьюзик и яндекс такси. Поэтому, когда они видят эти недоработки, в голове возникает вопрос "может надо было счет в тинькове открывать?". А мы, понятно, не хотим, чтобы они так думали, а любили только наш банк.
С UX долгом такие же правила, как и с техническим. Его надо:
📌 легализовать - объяснить бизнесу, почему он возникает и что будет, если на него забить.
📌 отдавать - в каждом спринте планировать немного времени на UX долг. Я обычно беру где-то 5%, т.е. 1-2 небольшие задачи.
Все знают про технический долг, попривыкли к этому понятию. Если бизнес занимает у разработки немного качества, чтобы сделать фичу супер быстро, то надо сразу планировать доработки и не тянуть с возвратом долга. В противном случае проекту плохеет: новые фичи занимают все больше времени, постоянные баги в продакшене, лица программистов становятся грустнее с каждым релизом 😔.
А бывает еще UX долг. Это аналогичная штука, только про интерфейс. Например, мы делаем экран транзакций в мобильном банке и решаем отложить вот эти задачи, чтобы поскорее выпустить фичу:
1️⃣ обработать состояние, если еще не было транзакций;
2️⃣ запомнить последнюю выбранную дату в сортировке;
3️⃣ разные стили в списке транзакций у юр. лиц и физ. лиц;
Действительно, без них можно жить какое-то время и даже пользоваться приложением. Но в 2021 люди привыкли к вылизанным интерфейсам в духе эппл мьюзик и яндекс такси. Поэтому, когда они видят эти недоработки, в голове возникает вопрос "может надо было счет в тинькове открывать?". А мы, понятно, не хотим, чтобы они так думали, а любили только наш банк.
С UX долгом такие же правила, как и с техническим. Его надо:
📌 легализовать - объяснить бизнесу, почему он возникает и что будет, если на него забить.
📌 отдавать - в каждом спринте планировать немного времени на UX долг. Я обычно беру где-то 5%, т.е. 1-2 небольшие задачи.
Грубая оценка
[Заказчик]: - хочу вот такую фичу
[Менеджер]: - ок, мы оценим и завтра пришлем сколько будет стоить
[З]: - да, ок, а скажи хотя бы примерно сколько? какой порядок цифр?
[Тимлид, пишет в личку]: - по разработке там работы +- на неделю
[М]: - 100 часов, или $4,000, если грубо
--------------------------------
Иногда нам нужно что-то быстро оценить. В этом случае можно воспользоваться вот такой формулой:
общая оценка = оценка на разработку * 2,5
То есть, если на девелопмент нужно 40 часов, то вся фича целиком, от требований до поставки, будет стоить заказчику 40*2,5 = 100 часов. Дальше умножаем на средний рейт и получаем стоимость.
Конечно, цифры примерные и на каждом проекте коэффициент будет разный. В банковском софте больше легаси и долгое тестирование, а в играх надо рисовать персонажей и уровни, там больше дизайна. В среднем цифра будет от 2,2 до 3.
И вот откуда она берется:
[Заказчик]: - хочу вот такую фичу
[Менеджер]: - ок, мы оценим и завтра пришлем сколько будет стоить
[З]: - да, ок, а скажи хотя бы примерно сколько? какой порядок цифр?
[Тимлид, пишет в личку]: - по разработке там работы +- на неделю
[М]: - 100 часов, или $4,000, если грубо
--------------------------------
Иногда нам нужно что-то быстро оценить. В этом случае можно воспользоваться вот такой формулой:
общая оценка = оценка на разработку * 2,5
То есть, если на девелопмент нужно 40 часов, то вся фича целиком, от требований до поставки, будет стоить заказчику 40*2,5 = 100 часов. Дальше умножаем на средний рейт и получаем стоимость.
Конечно, цифры примерные и на каждом проекте коэффициент будет разный. В банковском софте больше легаси и долгое тестирование, а в играх надо рисовать персонажей и уровни, там больше дизайна. В среднем цифра будет от 2,2 до 3.
И вот откуда она берется: