Управление проектами и командами — подходы, фреймворки и практика

Как управлять рисками бизнеса и продукта

Thu, 23 Jul 2026 13:31:54 +0300

Про риски

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

Новости последних дней все видели, поэтому подробно пересказывать их не буду. Для маркетплейса потеря даже крупного склада — неприятность, но всё же малая доля общей инфраструктуры. А вот для селлеров ситуация совсем другая.

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

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

Побег с маркетплейсов

На фоне происходящего коллега, который занимается нашим продуктом, задал логичный вопрос: не выстроятся ли теперь селлеры в очередь на выход с маркетплейсов?

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

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

Риск никуда не исчезнет, но бизнес найдёт способы с ним жить.

Риски продукта

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

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

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

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

Вероятность × ущерб

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

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

Вероятность × ущерб = приоритет риска.

Конечно, правильно оценить и вероятность, и последствия — отдельная задача. Но даже такая примитивная модель полезнее, чем обсуждение всех возможных катастроф подряд.

Коллега посоветовал составить карту рисков. И тут внезапно выяснилось, что её у нас нет ни по продукту, ни в агентстве. Опача. Будем исправлять. Возможно, заодно получится отдельный текст о том, как мы её составляли и что обнаружили.

Ну и короткое завершение. Кажется, мы вошли во вкус с выставками, поэтому осенью поедем ещё на одну или несколько. Ближайшая — E-Retail Forum 2026, которая пройдёт 22–23 сентября. Осталось не так много времени. Буду рад увидеться и пообщаться лично.

Рейтинг Рунета 2026: Webest вошел в топ-3 e-commerce, топ-10 Битрикс24 и топ-30 по технической поддержке

Wed, 01 Jul 2026 08:38:55 +0300

Астрологи объявили неделю двух постов 😊

Хвастаться, конечно, не очень красиво. Но если иногда не рассказать о своих результатах, то о них никто и не узнает.

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

В категории e-commerce заняли 3 место в среднем сегменте. Здесь, правда, сами себе поставили небольшую претензию. Средним сегментом мы, конечно, занимаемся, но уже около года целимся в верхний. Значит, в следующем рейтинге будем штурмовать уже его.

Среди CRM-интеграторов поднялись на 9 место. Год назад были ниже, так что движение идет в правильную сторону.

Отдельно радует направление Битрикс24. Мы остаемся одним из всего 10 партнеров, обладающих сертификатом Битрикс24 Enterprise среднего уровня, а также входим в топ-10 партнеров Битрикс24 по официальному рейтингу. Для нас это один из самых важных показателей.

Еще впервые попали в рейтинг по технической поддержке. Раньше он назывался «Развитие», теперь — просто «Поддержка». Итог — 24 место. Не первое, конечно, но специалистов в этой сфере очень много, поэтому буду скромно говорить, что мы в топ-30 России. Звучит вполне достойно. 🙂

Есть и другие отраслевые рейтинги — промышленность, пищевая отрасль и другие. Там тоже уверенно держимся в двадцатке и тридцатке, но это уже приятные бонусы.

И напоследок хочется сказать спасибо команде Рейтинга Рунета. За последний год они проделали действительно огромную работу: полностью переработали личный кабинет, сделали более прозрачным сбор и модерацию данных, серьезно улучшили сами рейтинги. Ну и отдельное удовольствие — наблюдать, что творилось в общем чате. 😄

Анатолий, Александр и вся команда Рейтинга Рунета — спасибо за ваш труд и удачи в следующих обновлениях!

Что на самом деле стоит за развитием репрайсера для маркетплейсов

Wed, 17 Jun 2026 17:07:20 +0300

«Да это Claude за час сделает»

Всем привет 👋

Пишу всё реже, но стараюсь хотя бы раз в неделю появляться здесь. Казалось бы, лето сезон отпусков, а B2B традиционно начинает жить в режиме «давайте после лета». Почти как «давайте после праздников».

Логично предположить, что свободного времени становится больше. Но почему-то получается ровно наоборот.

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

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

Свои прокси вместо арендованных

С самого начала продукт был довольно автономным и почти не зависел от внешних сервисов. Но одна зависимость всё-таки оставалась прокси.

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

Мы перепробовали множество провайдеров и сервисов. Где-то была слишком агрессивная ротация IP, где-то качество адресов оставляло желать лучшего. Но главная проблема была в другом отсутствие стабильности.

Система могла спокойно работать неделю, а потом в самый неподходящий момент прокси просто исчезал на несколько часов. Для репрайсера это критично.

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

Когда отказоустойчивость перестаёт быть теорией

Продолжая тему стабильности.

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

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

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

После этого стало понятно, что хранить все яйца в одной корзине плохая идея.

Сейчас мы активно смотрим в сторону Selectel, Яндекс Облака, Reg.ru и других площадок. Параллельно перестраиваем архитектуру продукта в сторону сервисного подхода. Не микросервисы ради модного слова, а разумное разделение системы на независимые компоненты.

В моём понимании «много сервисов» это не сотни. Уже около десяти независимых сервисов позволяют переживать отдельные сбои без остановки всей системы.

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

Что ещё делаем

Пока занимались вопросами надёжности, работа над самим продуктом не останавливалась.

Оптимизировали существующие стратегии, в том числе с точки зрения безопасности. Начали разработку стратегий на основе UNIT-экономики каждого товара. Продолжаем развивать поддержку новых площадок Золотое Яблоко, Лемана ПРО, М.Видео и других маркетплейсов.

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

Новый человек в команде продукта

И, наверное, самое важное изменение за последнее время.

К команде присоединился новый коллега. Я в шутку называю его цифровым разнорабочим. Да простит меня Рома.

По сути, он будет совмещать сразу несколько ролей: аккаунтинг, project management и product management.

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

Впрочем, как и всегда, время покажет.

Ну и напоследок.

Если давно хотели пересечься лично, напоминаю, что уже на следующей неделе будет Ecom Expo. Мы будем там со своим стендом. Подробности здесь: https://t.me/alexeyitru/206

Буду рад увидеться и пообщаться вживую.

Когда показатель становится целью: закон Гудхарта простыми словами

Thu, 04 Jun 2026 12:30:28 +0300

Когда показатель становится целью

Недавно узнал, что у всей этой истории с KPI и метриками есть официальное название — закон Гудхарта.

Хотя сама идея для меня новой не стала. За годы работы с проектами постоянно сталкивался с одной и той же проблемой.

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

И чем дольше в менеджменте, тем больше убеждаешься, что проблема обычно не в KPI. Проблема начинается тогда, когда люди перестают отличать цель от способа ее измерения.

Ломаем метрики

Почти любой показатель появляется как попытка ответить на разумный вопрос. Как понять, что все работает эффективно? Смотрим производительность. Как понять, что клиенты довольны? Измеряем NPS. Как понять, что поддержка справляется? Следим за скоростью ответа.

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

Хотите увеличить количество закрытых задач — получите дробление задач. Хотите загрузить сотрудников на 100% — получите очереди и постоянные переключения между работой. Хотите улучшить SLA — получите быстрые ответы вместо полезных. Хотите увеличить количество лидов — получите лиды. Правда, это совсем не гарантирует рост продаж.

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

Цифры как цель

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

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

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

Растягивать линейку

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

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

«Если этот показатель вырастет в два раза, станет ли клиенту, проекту или бизнесу действительно лучше?»

Если ответ неочевиден, то, возможно, мы измеряем не то.

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

Мы все еще пытаемся управлять реальностью через показатели. А реальность все еще оказывается сложнее отчетов.

Менеджер на автопилоте: почему мы принимаем тысячи решений в день и не управляем ими

Wed, 15 Apr 2026 16:37:13 +0300

Ты менеджер. Просто не осознал этого

Слово “менеджер” давно испортилось. Когда-то это был нормальный термин про управление, принятие решений, сейчас чаще что-то из серии “вам удобно говорить?” или просто размытая должность, за которой непонятно, что стоит. Цифровой разнорабочий. Менеджер по продажам, по клиентам, по развитию, по маркетингу — ролей много, но восприятие у слова стало довольно токсичным.

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

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

Есть оценка, что человек принимает десятки тысяч решений в день — часто называют цифру в районе 30–35 тысяч. Точность можно обсуждать, но сам масштаб понятен: решений действительно много, и большая их часть проходит мимо нашего внимания. Мы действуем на автопилоте, опираясь на опыт, привычки и уже сформированные сценарии поведения. Это нормально и даже необходимо, иначе на базовые вещи просто не хватило бы ресурса.

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

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

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

Почему классический репрайсер для Ozon и Wildberries уже не работает — и что мы строим вместо него

Wed, 19 Nov 2025 14:39:32 +0300

SaaS был ошибкой? Возможно. Часть 4

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

Месяц кастдевов

За это время провёл около двадцати интервью с бизнесом и людьми, которые так или иначе связаны с маркетплейсами: от продуктовых специалистов до руководителей направлений МП. Хотел понять простую вещь — кто и как управляет ценами, где автоматизация действительно работает, а где все по-старинке.

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

А вот в enterprise-историях проблема подтверждается. Каждый решает её по-своему, костылями и полуавтоматом. У селлеров с небольшим ассортиментом всё проще — там хватает существующих сервисов. Я насчитал больше двадцати живых решений, и у каждого свои особенности: ограничение на количество товаров, странные тарифы и отсутствие нормальных интеграций. Всё руками, о связке с 1С или динамическими ценами часто даже не мечтают.

Сменить позиционирование

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

Так получается точнее и честнее отражать то, что мы реально делаем — и то, чего нет у конкурентов.

Что сделали по разработке

Перезапустили сайт решения. Хотелось собрать всё на Тильде, но пошли другим путём — сделали максимально примитивно, чтобы проверить конверсию самого подхода. Личного кабинета пока нет, но рассчитываем довести его до ума за ближайшие одну–три недели.

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

Личный кабинет стал чуть красивее обычного орчида, но ещё не тот результат, от которого отваливается челюсть, но в целом окей. Зато сделали авторизацию через email и OTP — СМС подключим позже.

Интересные находоки

Нашли хак на Ozon. Если товар стоит в акции, менять цену нельзя — она пишется, но берётся медианная. Однако если сначала вынуть товар из акции, обновить цену и вернуть обратно — всё работает. Абсолютно легально, пока.

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

Добавили альтернативный источник данных — из личного кабинета маркетплейсов. Точность ниже, но скорость выше. Правда, не для всех товаров.

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

Что дальше

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

Параллельно будем выходить в аутрич через Telegram, чтобы дотянуться до среднего и крупного сегмента. Тут уже интереснее — посмотрим, что получится.

В разговоры с экспертами добавился новый блок — прикидка трендов. Что будет дальше?

API может стать платным. Больно, но не смертельно. Цена персонализируется до безумия — непонятно, что будет с РРЦ и МРЦ. Запрет на изменение цен по API? Сомнительно, но и на это у нас есть запасной вариант.

Далее по плану.

Запускаем SaaS.
Доделываем стратегии.
Включаем рекламу и аутрич.
А дальше — посмотрим, что покажут цифры и люди.

Про декомпозицию

Thu, 06 Nov 2025 09:15:11 +0300

Если упростить до сути, управление проектами и людьми — это искусство декомпозиции.

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

Но именно на этом месте всё обычно и ломается. Что-то вроде сделали, а вроде и нет. И как только начинаешь разбираться — никто толком не может сказать, что именно готово, а что ещё “в работе”. Самая частая фраза: «мы этим занимались». Это значит: ничего не готово, но очень хочется, чтобы казалось, будто процесс идёт.

Когда слышу “готово на 80%”, внутри уже загорается лампочка. Эти 80% — просто способ не сказать “не сделал”. Это не цифра, это способ не брать ответственность. Поэтому у любого адекватного менеджера рано или поздно появляется привычка резать задачи до тех пор, пока не останется только два состояния: сделано / не сделано.

Иногда доходишь до смешного. Даёшь человеку простое поручение — например, согласовать макет с клиентом. Через неделю он рассказывает, что дизайнер ещё думает, клиент не ответил, а в чате не было тегов. И вроде бы “все работали”, но конкретного результата нет. В этот момент становится ясно: проблема не в макете, а в том, что задачу нужно было разбить до уровня “отправить макет”, “дождаться комментария”, “внести правку”.

Менеджмент — это не про контроль и отчёты, а про честность. Про умение признать реальность без процентов и “почти готово”. Если задача не декомпозирована — она будет бесконечной. Если декомпозирована — у неё есть шанс быть завершённой.

Когда команда начинает мыслить в этих категориях, исчезают оправдания и споры “что имелось в виду”. Каждый видит границу: вот задача, вот результат. Всё остальное — разговоры для галочки.

Корпоративные IT-термины и англицизмы: язык заказчика в B2B

Sat, 01 Nov 2025 16:32:03 +0300

Ихние диалекты

Как у вас с английским? Уже выучили или какой-то другой начали учить?

У меня тоже не очень. На созвонах с англоговорящими людьми — а они, как ни странно, всё ещё иногда случаются в текущих обстоятельствах — я как очень умное животное: всё понимаю, а ответить ничего не могу. Сижу, смотрю и киваю. Наверное, это нарабатывается практикой. Но сегодня не об этом.

Диалекты профессий

Многие профессиональные сферы — стройка, финтех, медицина, и IT не исключение — со временем обрастают сленгом, англицизмами и прочими артефактами.

Вот только верхушка айсберга: CAPEX, OPEX, MVP, MLP, скоринг, комплаенс, чекаут, PIN, юнит-тесты, легаси, BRD, PROD, витрина, домен, CI/CD, релиз.

Половину из этого можно спутать с названиями таблеток.

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

Почему без «своего» языка не договориться

B2B-бизнес — это про людей. Чтобы договориться, нужно уметь общаться. А чтобы общение было продуктивным — нужно говорить на одном языке. Мысль не новая, даже старая: «Говорите с заказчиком на его языке». Но по факту это единственный способ, чтобы вас поняли.

Если мы говорим про микробизнес — там всё просто и по делу: “надо, чтобы работало”. В малом и среднем бизнесе — уже веселее, но всё ещё понятно. А вот у крупных компаний начинается корпоративный диалект.

У CTO — свой. У продукта и проджекта — свой. У владельца домена — свой. У e-com-директора — тоже свой. А заказчик, как правило, не один. И нередко они между собой говорят на разных языках — а роль переводчика достается тебе.

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

Лучше переспросить, чем не понять

Если чувствуете, что не дотягиваете по “языку” — лучше подготовьтесь. А если не получилось — переспросите, если не понял. Лучше показаться глухим, чем потом неправильно всё сделать.

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

Так что изучайте корпоративные диалекты — особенно если работаете в IT или B2B. Вероятно, вам понадобятся разные диалекты — не только IT, но и отраслевые: e-commerce, финтех, стройка и так далее.

Говорите на «ихнем» — и жизнь станет сильно проще.
А какие диалекты знаете вы?

Как я превратил крутого разработчика в руководителя и потерял обоих — история управленческого факапа

Mon, 20 Oct 2025 15:35:35 +0300

2016–2018: когда нас было девять

Те годы помню до деталей: нас девять человек, горячие, голодные, без лишней бюрократии. И вот к нам приходит парень — назовём его Антон. В резюме — «веб-разработчик» без узкой специализации. Сказал честно: «Умею немного, но быстро учусь». Конкурентов в офлайне тогда не было вовсе. Взяли.

Антон рос как на дрожжах. Подхватывал горящие задачи, часто выручал. Мы подтягивали вознаграждение, прокачивали стек, перестраивали процессы. Постепенно стало ясно: доступные у нас задачи и вилка дохода перестали его держать. Он перерос рамки роли и по ожиданиям, и по уровню.

Поворот не туда: «давай в тимлиды»

Мы начали думать, чем его загрузить, чтобы и человеку интересно, и компании польза. Тогда ещё не было чётких контуров по ролям, «лидство» существовало больше по факту, чем по документам. Мы нарисовали мотивацию, собрали пул задач. Получилось скорее про организацию команды, чем про архитектуру и сложный код — то есть ближе к team lead, а не к tech lead.

Антон согласился. Формально всё обсудили: цели, задачи, ответственность. На практике — человек просто хотел писать код. Мы этого не услышали. Полгода, примерно год — и однажды вечером он говорит: «Мне пора. Хочу писать код, который штурмует космос, работать над сложными задачами в сильной продуктовой команде».

Было больно. В Антоне концентрировалось много технологий и контекстов. По деньгам перебить оффер не могли: почти х3 к нашему потолку. Разошлись цивилизованно, договорились о передаче дел. Связь не потеряли — до сих пор общаемся, обмениваемся опытом.

Ирония судьбы

Самое интересное началось позже. Антон ушёл «от управления людьми» к «божественному коду» — и через год в новой компании его снова подключили к руководству командой. Классическая траектория сильного спеца: чем лучше кодер, тем выше шанс, что его начнут тянуть в менеджмент, нравится ему это или нет. Он уже смеётся: прошёл дорогие курсы по управлению и лидерству, разбирается в людях не хуже, чем в бэкенде.

Что было не так на нашей стороне

Мы не объяснили человеку логику роли и не проверили, зачем она ему. Слушали рынок, KPI и наши потребности, но недостаточно слушали Антона. Ему нужен был фокус на сложном коде, архитектуре, R&D. Мы предложили организационную повестку и «немного кода». В итоге потеряли звёздочку — и это целиком наш косяк.

Справедливости ради, команда от той истории стала сильнее. Мы формализовали роли, разделили Team Lead и Tech Lead, перестроили грейды и мотивацию. А Антон стал ещё круче как специалист и теперь осознанно совмещает техническую глубину с лидерством.

Что бы я сделал сейчас

Во-первых, честный карьеркарт: две развилки — Tech Lead (глубина, архитектура, сложные задачи, минимум митингов) и Team Lead (люди, процессы, цели, много коммуникаций). Показал бы риски и рутину каждой траектории, а не только плюсы.

Во-вторых, прототип роли на 1–2 месяца. Не «назначили и поплыли», а проверили интерес и пригодность в коротком цикле с обратной связью.

В-третьих, личные мотивы важнее оргструктуры. Если человек горит кодом — дай ему «космос»: тяжёлые проекты, ответственность за архитектуру, время на исследования. Не пытайся «починить» мотивацию окладом и приставкой «лид» в должности.

Итог

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

Эта история чем-то рифмуется с другой — про Фёдора. Если не читали, загляните: https://t.me/alexeyitru/153

Технический долг и legacy проекты — как архитектура кода влияет на скорость релизов и стоимость поддержки

Mon, 22 Sep 2025 10:25:50 +0300

Мы много работаем с легаси. Основной пул наших клиентов — это проекты на развитие и поддержку текущих систем. И именно здесь как нельзя лучше всплывают два вопроса: стоимость поддержки кода и скорость релизов.

Стоимость поддержки

Когда идёт разработка нового проекта — сайта, интернет-магазина, B2B-платформы или чего-то похожего — мало кто думает о том, сколько будет стоить дальнейшее развитие. Решения, которые закладываются на старте, часто не просто не адаптированы под поддержку, они прямо ей сопротивляются.

И это, наверное, нормально. Я уже писал, почему веб всё ещё делают плохо. Но ситуация кардинально меняется, когда работаешь с долгосрочным проектом. Здесь нельзя просто «подписать акты, отдать проект и пусть он живёт сам по себе». На таких проектах любой костыль будет использован против вас.

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

Архитектура и варианты решений

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

Да, работа по проектированию и архитектуре увеличивает стоимость конкретной задачи. Но зато в будущем может сберечь от рефакторинга целых блоков (а иногда и всего проекта). Оценить это сложно, но сердце подсказывает: так правильно.

Скорость релизов и TTM

И вот вторая история. Чем хуже код, тем сложнее релизы, тем дольше time to market. А бизнес это ненавидит. Он хочет: придумал задачу — передал идею — вчера уже на боевом проекте. В жизни так не работает.

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

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

Можно очень сильно автоматизировать процесс релизов, но на это уйдут часы и деньги — не всякий бизнес на это готов. Поэтому TTM всегда компромисс: сколько времени даём на разработку, тестирование и релиз.

В идеале релизы должны быть минимальными по времени и маленькими по объёму. Их проще тестировать, проще выкатывать и безопаснее. И лучше делать их чаще, чтобы не копилась очередь и зависимости между задачами.

Вывод

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

Лавина запросов — не проблема, а ресурс: как превратить поток задач в рост проекта

Wed, 03 Sep 2025 12:32:30 +0300

Недавно ко мне зашёл один из наших руководителей проектов. На лице усталость и раздражение:
— Наш маркетинг достал. Постоянно сыплет задачами, всё срочно, всё горит.

Да ещё и сам клиент подкидывает сверху — кто из маркетинга, кто из продаж, кто из IT. Кругом бардак, чаты разрываются, звонки без остановки. Невозможно работать!

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

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

Во-вторых, задача менеджера проекта — превратить этот хаотичный водопад в ручеёк. К нам пришла идея? Мы её приняли, оценили, дали экспертное мнение. Иногда полезно прямо сказать: «Эта доработка может поломать другой компонент системы». Это фильтр. Если после оценки клиент подтверждает — берём в работу. Всё. Вместо бардака получается выстроенный поток, где у команды есть ясность, а у клиента — уверенность, что его инициативы слышат и доводят до результата.

И тут важный момент. Если вы понимаете, что задачи сыпятся из разных мест — чаты, таск-трекеры, письма на почте — это, конечно, супер клиентоориентированно, но вы подливаете бензин в пожар. С этим можно работать, но долго вы не протянете. Лучше свести всё в одно место, которое удобно для обеих сторон: задачник, только почта, система постановки задач или, в крайнем случае, Google-таблица. Это сразу уменьшит хаос в несколько раз.

Но есть ещё один нюанс. В каждой компании всегда есть человек, который отвечает за контракт с подрядчиком. Чаще всего это IT-директор, e-com директор или кто-то рядом. И договор у вас по сути именно с ним, а не с десятком разрозненных сотрудников.

И тут возможны разные сценарии:

Первый вариант — все задачи проходят через этого человека. Неважно, откуда прилетела идея: маркетинг, продажи, колл-центр. Оценку и резолюцию ставит он. Удобно и понятно.

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

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

Всё упирается в договорённости и зрелость отношений. Иногда клиенту действительно нужна жёсткая фильтрация, а иногда наоборот — скорость важнее.

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

Сколько реально стоит создать корпоративный сайт на Битриксе: миф об экономии внутренней команды

Fri, 22 Aug 2025 10:51:26 +0300

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

Речь зашла о сроках. Проект простой: корпоративный сайт с каталогом, фильтрами, корзиной и формой заказа. Ничего необычного. Сделали за пять месяцев.

Коллега был одновременно и менеджером проекта, и тестировщиком. В команде — два человека, битрикс-разработчик и верстальщик. Прикинули по-быстрому: у нас подобное заняло бы около 600 часов. При ставке 3 000 ₽ выходит 1.8 млн рублей.

На что последовал ответ:
— «Очень дорого. Мы сделали почти в два раза дешевле».
По зарплатам получилось примерно 900 тысяч.

И вот тут во мне закипело чувство справедливости.

Почему 900 тысяч — это иллюзия

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

Второе. Менеджерские часы никто не считал. Коллега вел проект как менеджер, но это тоже труд и время. По сути это затраты между строк.

Третье. Ошибки были точно. Не поверю, что код писался без багов, а тестирование заняло ноль часов. Коллега это взял на себя.

Четвёртое. Скрытые расходы. Рабочее место, техника, софт, поиск специалистов, собеседования, отпускные, больничные, срывы сроков — всё это тоже деньги.

Если всё посчитать честно, выйдет даже больше тех же самых 2 млн рублей.

Вывод

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

Да, внутренняя команда может быть суперэффективной — особенно если проект большой и сложный, а команда слажена. Яркий тому пример финтех, на core компетенции всегда внутри. Но если проект разовый, редкий или построен на серых схемах налоговой оптимизации, то реальная цена такой «экономии» выходит золотой.

Иногда платить дороже — на самом деле дешевле.

История одного факапа

Thu, 17 Jul 2025 15:11:47 +0300

Проект сгорел, подрядчик исчез, а долг остался

Давно собирался написать большой пост с историй своих факапов. Но понял: факапов было столько, и каждый тянет на отдельную историю, что в один текст не уместишь. Так что запускаю рубрику. Буду делиться своими личными провалами за 10 лет в менеджменте.

Ну а чтобы было не только поучительно, но и весело — делаем из этого небольшую исповедальню.
Если вы тоже когда-то факапнули — а кто нет? — и хотите рассказать свою историю анонимно или нет, напишите мне в личку и история появиться на канале. Учиться на ошибках — лучше, чем делать вид, что их не было.

История факапа
Дело было давно. Мы были молодые, амбициозные и «динамично развивающиеся». Мобильное приложение, которые мы тогда не умели делать сами, но всё равно взялись. История закончилась долгами и испарившимся заказчиком.

Погнали. Быстро нанимать тогда не умели, решили отдать проект на субподряд. Пока делался UX/UI — нашли подрядчика, заключили договор, стартовали. Месяц прошёл, пошли какие-то наработки, пара экранов даже появилась — и подрядчик пропадает. 50% по этапу уже оплачено подрядчику. Телефон молчит. Время уходит. Аванс был ошибкой.

Окей, ищем нового.
Находим. Он готов подключиться быстро, но работает по Time & Material. Ладно, смету вроде прикинули, пообещали уложиться.
Дальше — классика:

появляются новые хотелки от клиента, переоценкой мы тогда не владели,
всплывают косяки по дизайну,
сроки съедены, но мы всё ещё далеко от фианал.

Бюджет улетает за 100%+. Подрядчик работает честно, наверное, часы отгружает. Изначальный бюджет уже закончился, но мы не тормозим процесс, рассчитывая договориться с заказчиком на допфинансирование.

Спойлер: не договорились.

Переговоры тянулись несколько месяцев. Потом заказчик просто сказал: «Проект закрыт. Денег больше не будет».

Мы с подрядчиком довели проект до рабочего состояния и передали всё, что было сделано. Но долг перед подрядчиком остался. Выплачивали его ещё полгода из своего кармана.

Выводы:

Привлекаешь подрядчика? Зеркаль условия по срокам, оплате и ответственности из основного договора.
Даже по T&M нужна от них смета и обязательства.
А если хочешь спать спокойно — держи ключевую экспертизу внутри, как мы это делаем сейчас.

С тех пор я больше не надеюсь, что «как-нибудь разрулим». Только договор, только контроль, только хардкор.

Метод параноика Вадима Митякина: что внутри, для кого и как работает в агентстве

Mon, 07 Jul 2025 08:51:44 +0300

Кто такой Project Runner и зачем он нужен?

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

Вадим написал книгу «Метод параноика». Написана, на мой взгляд, не столько для студий и агентств, сколько для продуктов, стартапов и людей, которые хотят делать не просто задачи, а смыслы. Но читать — обязательно. Особенно если вы не хотите остаться просто фабрикой задач.

Первое впечатление

Меня метод зацепил с самого начала, показался чем то родным как будто всю жизнь так и делал. Но одновременно с этим внутри было какое-то сопротивление, неочевидное, подсознательное. Знаете, из серии: «Это классно, но у нас не взлетит. Это ведь про какой-то идеальный мир». И только к финалу книги щёлкнуло — я всё это время смотрел на метод через призму аутсорса. На самом деле метод — это не про «под ключ». Это про продюсирование результата, про то, как довести проект до смысла. И в этом контексте всё встало на свои места.

Многослойный пирог

Метод кажется безумно логичным: все части на своих местах. Когда читаешь — ощущение, что «вроде бы и так делал», но на самом деле — нет. Он многослойный, охватывает все уровни продукта и фазы развития.

Книга делит проекты на три типа:

Мозги — уникальные задачи, стартапы, поиск решений в условиях неопределенности. Здесь Project Runner — ключевая фигура.
Седина — когда нужно адаптировать уже известное, внедрить в конкретный контекст.
Процедуры — рутина, где всё формализовано. Но и здесь Project Runner может быть «спящей ролью», которая следит, чтобы процессы не вывалились в хаос.

Метод помогает понять, на какой стадии сейчас находится проект, и какие инструменты, роли и подходы включать. Это не «фреймворк для всего», а система включения нужных ресурсов в нужный момент.

Первая мысль: ресурсы не должны быть включены «всегда». Они подключаются только в нужный момент, как завещали дяди из Toyota. Не нужно тянуть на старте проектировщика интерфейсов или дизайнера, если мы ещё в стратегической концепции. И наоборот — не держим стратегов, когда уже клепаем кнопки.

Вторая мысль: каждая задача, решение, встреча должны снижать неопределённость. Не просто «что-то делать», а делать то, что убирает туман. Если задача этого не делает — возможно, она не нужна. Если она увеличивает неопределённость — её точно не надо делать. А скорость снижения неопределённости должна быть выше, чем скорость сжигания бюджета. Всё просто: туман должен рассеиваться быстрее, чем заканчиваются деньги.

Третья мысль: важно задавать правильные вопросы на правильном уровне — это матрица:
по горизонтали — стадии проекта: Концептуализация → Систематизация → Проектирование → Реализация;
по вертикали — уровни: бизнес → функциональный → интерфейсный → технический → организационный.

Это как работать с микроскопом: на каждом увеличении ты видишь новую структуру. Так и здесь — на каждом уровне и на каждой стадии должны звучать свои вопросы. Ошибка — пытаться проектировать интерфейс, когда ещё не сформулирована функция.

Метод учит видеть эту матрицу и работать с ней. Без перегрева,без «давайте всё сразу». Только нужные вопросы, нужные роли, в нужное время.

PM ≠ Project Runner

В агентствах PM часто — это координатор, в котором совмещены 3 — 4 роли. Но по Митякину — нужен не координатор, а ведущий. Человек, который держит в голове, зачем вообще весь этот проект, куда он ведёт, и что делать, если клиент сам не знает, чего хочет.

Это не «всё разрулить» — это «понять, во что мы играем, и зачем».

Project Runner — это не должность, а функция, «мета-роль». В процедурах он не нужен. В мозгах — рулит. В седине — помогает не сбиться.

Разработка — не старт, а финал

Проекты нужно начинать не с ТЗ. Сначала — гипотезы, цели, архитектура, риски. Настоящие проекты стартуют с этапа продумывания, а не сразу «пилить». Scrum, Kanban, Agile — не спасут, если нет смысла. А если он есть, то и метод подберется.

Нечеткая постановка — и это нормально

Довольно часто у заказчика в голове проект сформирован на уровне гипотез: половина из привычки, остальное — «как у конкурентов». Наша задача — не выполнить хотелки, а довести до результата. И если нужно — переосмыслить саму задачу. Project Runner в агентстве — это не тот, кто кидает правки в чат. Это тот, кто ведёт к цели, несмотря на неопределённость.

Продюсирование > управление задачами

Если у вас всё ещё «таск-трекер + чатик + заказчик шлёт правки», то это не управление. Это диспетчерская. Настоящее управление — это про приоритеты, фокус на ценности, про «зачем», а не «что делаем».

Книга ярко показывает: разработка — это лишь 40% работы, остальное — договорённости, управление ожиданиями, этапы продумывания, переупаковки, выстраивания смысла.

Где это работает

Лучшее применение метода — стартапы и запуск новых направлений. Особенно там, где высокая доля неопределённости. Собственно обложка книги про это: “снижать неопределенность на каждой задача”. Но и в корпорациях роль Project Runner’а может оживать — например, в моментах дизрапта или пересборки процессов.

Хорошая метафора: проджект-раннер — как watchdog, который следит, чтобы процедуры не развалились, а если развалились — запускает перезапуск.

Вывод

Нужно стремиться к проектам из категории «мозги», а не «процедуры». Там сложнее, но интереснее. Там больше денег. Там вы нужны как партнёр, а не как исполнитель.

Если ты просто делаешь, что просят — ты заменим.
Если ты ведёшь и думаешь — ты партнёр.

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

Если после прочитанного вы чувствуете, что хотите глубже погрузиться в тему, — не откладывайте.
📘 Вот ссылка на саму книгу — «Метод параноика».
📡 И авторский канал Вадима Митякина в Telegram.

Сколько часов мы реально работаем в год: расчёт на 2025 для IT и аутсорс

Fri, 13 Jun 2025 10:20:19 +0300

В праздничные дни особенно уместно поговорить о рабочем времени.Сколько мы действительно работаем — не по договору, а по факту?

В IT и в аутсорс/аутстаф-разработке принята условная «единица измерения» — 40 часов в неделю. Это считается стандартной загрузкой: менеджеры планируют задачи, финансы, выручку и загрузку команды, отталкиваясь от этой цифры.

Формально выходит:
4 недели × 40 часов = 160 часов в месяц,
или 1920 часов в год.

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

Сколько реально рабочих часов в году?

Берём 2025 год:

365 дней = 52 недели
247 рабочих дней (с учётом праздников и выходных)
Сокращённые предпраздничные дни — минус 1 час

Итого:
1972 часа — это максимум, сколько может «отработать» специалист в году, если он не болеет, не берёт отпуск и не сталкивается с форс-мажорами.

Но жизнь не идеальна. Добавим реальности:

Минус отпуск, минус больничный, минус «туда-сюда»

Отпуск: 28 календарных дней = ~20 рабочих = 160 часов
Больничный: допустим 7 дней = 40 часов
Быт и форс-мажоры: ещё минус 1 неделя в году = ещё 40 часов

Вычитаем:
1972 − 160 − 40 − 40 = 1732 часа

Теперь делим на 52 недели:
≈33,3 часа в неделю

Зачем эта математика?

Разница между плановыми 40 и фактическими 33 часами — это не просто «семь часов туда-сюда». Это 17,5% времени, которого у вас нет. Если проект рассчитан на 3 месяца — вы теряете почти две недели.

И это ещё без учёта того, что не все 33 часа в неделе — продуктивные. Многие исследования показывают, что фокусной работы у разработчика 5–6 часов в день, максимум. Остальное — совещания, переключения, задачи не по плану и просто усталость.

Что с этим делать?

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

Итого

Можно сколько угодно твердить про героев которые работают по 10–12 часов в день. Но сколько из них — действительно работа? И сколько недель подряд вы выдержите в таком темпе, не сгорев?

Так что планируйте здраво. Рассчитывайте реальные ресурсы, а не фантазии.
И — с прошедшими праздниками. Отдохнуть тоже важно.

Индивидуальные планы развития вместо грейдов: как мы ушли от матриц компетенций

Thu, 22 May 2025 15:39:08 +0300

У нас в студии нет грейдов. Точнее, они есть, но называются иначе — и суть в них не в погонах.

Лет шесть-семь назад мы подошли к вопросу системно: изучили всё, что было на тот момент в рунете и за рубежом. Почти везде это были матрицы компетенций: теория + практика. Например, джун-верстальщик должен знать Git — сначала сдать теоретическую часть, потом показать вживую, что не только кнопки знает, но и коммитить умеет.

Мы составили такие же чек-листы: навыки, требования, уровни — и тут же в них утонули.

Где грейды, там боль

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

Плюс всегда нужна групповая оценка. Один наставник — это взгляд под углом. Лучше два-три, да ещё и чтобы знали, на каких проектах работал человек.

А ещё ИИ теперь сдаёт любую лабораторную на «отлично». Остаётся только live coding. И ещё с десяток нюансов, которые сложно систематизировать.

Я вообще скептически отношусь к грейдам. В одной компании ты бог-сеньор, в другой — не дотягиваешь до мидла. Всё зависит от задач, процессов, ожиданий. У нас один критерий: может человек решить задачу на конкретном проекте — или нет. Всё остальное — удобная иллюзия. Такой себе договорнячок, чтобы HR-у и менеджеру было проще жить.

А уж как джунов дрессируют к собеседованиям на аутсорсе — это вообще отдельный жанр. Там и цирк, и театр, и шаманские ритуалы. Надо будет как-нибудь рассказать отдельно.

Вместо грейдов — Stage

В какой-то момент мы решили изменить тактику. Начали внедрять индивидуальные планы развития. Мы их назвали Stage. Начинается с Stage 1 — база: Git, инструменты, основы. Дальше идёт специализация под человека.

Каждый Stage — это блок теории (устный экзамен на 1–2 часа) + практика. Идеально — если практическое задание можно реализовать прямо в текущем проекте. Если нет — делаем пет-проект. Перед сдачей специалист показывает решение, принимающие готовят вопросы. Три грубые ошибки — пересдача не раньше, чем через три месяца.

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

Почти data driven

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

Задумка классная. Но на практике, как всегда, всплывает куча нюансов. Пока всё не складывается в цельную систему, но мы не бросаем это дело. Поднакопим ещё данных — и соберём универсальную таблицу.

Ну а пока идите за кофе к мидлу-баристе, вас уже везёт сеньор-таксист.

Как управлять рисками в проектах и бизнесе: без формул, но с пользой

Mon, 19 May 2025 18:10:25 +0300

Управление рисками — тема, которую часто откладывают «на потом». Но именно от неё зависит, будет ли ваш проект успешным или станет очередной историей о провале.

В этой статье разберёмся, что такое риски простыми словами, почему важно ими управлять, как это делать без сложных формул и с реальной пользой. Если вы руководите проектами, компанией или отделом — это руководство для вас.

Что такое риск в проекте простыми словами

Риск — это потенциальное негативное событие, которое может повлиять на проект. Ключевое слово здесь — «может». Пока событие не произошло, оно остаётся в статусе риска. Простой пример: подрядчик может не успеть сдать задачу в срок. Это риск. А если уже не сдал — это факт, с которым надо работать.

Риски есть в любом проекте — в IT, строительстве, производстве, маркетинге. Это не признак плохого планирования, а естественная часть работы. Главное — уметь их распознавать заранее и готовиться к ним.

Почему важно управлять рисками

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

Вот что происходит, если не управлять рисками:

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

Управление рисками — это способ сделать проект более предсказуемым, команду — спокойнее, а бизнес — стабильнее.

Как работает классическое управление рисками

В классике риск оценивается по формуле:

Риск = Вероятность наступления × Ущерб

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

На практике это выглядит так:

Всплыл риск: например, есть шанс, что сервер не выдержит нагрузку.
Мы оцениваем:
- Вероятность: 40%
- Потери: 1 миллион рублей в случае падения
Сравниваем с затратами на устранение: апгрейд серверов за 150 тысяч.

Вывод: апгрейд выгоден — устраняем риск.

Это и есть основа риск-менеджмента: сравнивать цену проблемы с ценой её предотвращения.

Как управлять рисками без математики

Не все работают в корпорациях с отделом оценки рисков. В реальности — вы руководите отделом, агентством или проектом и у вас нет времени строить матрицы в Excel. Что делать?

Используйте экспертную оценку:

Соберите команду и проведите 15-минутную сессию: что может пойти не так?
Присвойте каждому риску «глазомерную» оценку: высокий / средний / низкий.
Отметьте, какие риски критичны и требуют действий.

Визуальные инструменты:

Таблица рисков: риск, последствия, действия, ответственный.
Матрица вероятности / влияния (можно от руки).

Главное — не точность, а системность. Даже простейшее обсуждение рисков лучше, чем их полное игнорирование.

Виды рисков в проектах и бизнесе

Разделим риски по характеру:

Финансовые — перерасход бюджета, неоплаченные счета, рост цен.
Технические — баги, несовместимость ПО, отказ оборудования.
Репутационные — негатив от клиента, провал публичного релиза.
Юридические — нарушение договора, санкции, споры.
Человеческий фактор — выгорание, увольнение ключевого сотрудника, ошибки исполнителей.

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

Риски и возможности — две стороны одной монеты

Управление рисками традиционно фокусируется на негативе. Но ведь есть и обратная сторона: возможности. Это позитивные события, которые могут произойти, если вы будете готовы их заметить.

Пример: ваш конкурент закрывает бизнес. Если у вас есть гибкость и готовый план, вы можете перехватить его клиентов. Это шанс. Но если вы ничего не предпримете — упустите.

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

Как внедрить управление рисками в компанию или проект

Если вы хотите, чтобы риск-менеджмент работал не только в вашей голове, а стал частью команды — внедряйте пошагово:

Регулярные обсуждения рисков — на старте проекта, при изменениях, раз в неделю.
Фиксация в общем документе — Notion, Google Docs, Trello, что угодно.
Ответственный за каждый риск — один человек = один риск.
Протокол действий — если риск наступил, что делаем?
Ретроспектива — какие риски сработали, что не учли?

Так вы создадите культуру предсказуемости. А это редкость.

Типичные ошибки при работе с рисками

Формальное заполнение — «для галочки». Пустая таблица — это хуже, чем отсутствие таблицы.
Нет ответственности — если не назначен человек, риск никто не контролирует.
Иллюзия контроля — отметили риск, но ничего не предприняли.
Не анализируют ошибки — те же риски повторяются из проекта в проект.

Избегая этих ошибок, вы уже на шаг впереди.

Заключение: что можно сделать уже завтра

Проведите короткую сессию с командой: «Какие риски вы видите в этом проекте?»
Составьте простую таблицу: риск, последствия, действия, ответственный.
Назначьте человека, кто будет следить за обновлением этого списка.

Управление рисками — это не про страх. Это про ответственность и зрелость. И как показывает практика: те, кто заранее думает о плохом — быстрее приходят к хорошему.

Часовая ставка в агентстве: почему цена за час ничего не значит

Mon, 05 May 2025 10:31:45 +0300

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

Рынок снова смотрит на фикс
Сейчас всё больше клиентов склоняются к моделям с фиксированной стоимостью. Особенно в новых проектах: никто не хочет брать на себя риски time & material или платить за ретейнер. И это, надо сказать, логично — в нестабильной ситуации все ищут предсказуемости.

Но там, где уже идёт развитие существующих решения или проекта, time & material всё ещё живёт и процветает. А вот ретейнер — штука нишевая, по крайней мере, в нашем опыте он не прижился.

Когда дешево — не всегда выгодно
Возьмём пример. У нас есть проект на 1000 часов в месяц — классика: команда, задачи, гибкий формат.

Теперь представим, что заказчик выбрал подрядчика с сильно заниженной ставкой. Выбирали по тендеру, ориентируясь на цену. Ну что ж, поздравляю: скорее всего, вам «грузят» час за два, а то и за три

Простой кейс. Нужно прикрутить новый способ оплаты. Исполнитель заявляет 9 часов. По факту с головой хватает 4. Красота: ставка по факту x2. Кто-то честно выставит именно 4, но далеко не все.

Не только часы, но и команда
Важно понимать: разные агентства вкладывают в оценку разный объём работы. В одном случае — фулстек-разработчик и менеджер. Придумали, сделали, протестировали, выкатили. Быстро, просто, но с рисками.

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

Сравнить объективно — почти нереально
Сравнить оценки разных подрядчиков на одну и ту же задачу — почти невозможно. Никто этим не занимается. Поэтому остаётся только одно: доверие

Если обе стороны нацелены на долгосрочное сотрудничество, не побоюсь слова — партнёрство, — то обманывать просто невыгодно. Это сработает один раз, а репутацию потом не отмоешь.

Не верьте «показательным» ставкам
Когда агентство на конференции заявляет: «У нас ставка — 5000 ₽ в час, и так надо работать!», а потом в тендере ставит 1500 — это вызывает как минимум недоумение

Да, кто-то скажет: «Они просто заходят в клиента». Но когда контракт многолетний, со множеством технологий — это уже не просто «вход». Это стратегия. Слишком долгая, слишком сомнительная.

В итоге получается, что многие кейсы и доклады на тему ставок можно смело делить пополам. А то и на три. Кто-то продаёт специалистов за полторы копейки, а получает при этом один.

В завершение
Эта тема родилась из наблюдений за тендерами. Главный вывод простой: ставка — не показатель. А доверие, прозрачность и адекватная коммуникация — всё ещё лучшая валюта в агентском бизнесе

Отдельно хочу отметить положительный тренд: чтобы избежать истории «час за два», последнее время на старте переговоров или тендера просят оценить 2–3 небольшие задачи в часах. Это убивает двух зайцев — помогает понять, какой будет порядок оценки и стоимость задач, а заодно показывает варианты реализации задачи что косвенно показывает компетенции.

Концерт по заявкам: как мы автоматизировали Яндекс.Трекер

Mon, 17 Mar 2025 09:18:55 +0300

Недавно в одном из профессиональных чатов снова всплыл вопрос о Яндекс.Трекере. Оказалось, что мы не единственные, кто активно использует его в работе агентства.

Хотя, по моим субъективным наблюдениям, большинство коллег все-таки сидят на Битриксе24 или Jira — но это уже другая история.

За несколько лет использования Трекера мы успели хорошо разобраться в системе. Она своеобразная, со своими особенностями, но в целом довольно гибкая и мощная. Где-то лежит начатая статья про всю автоматизацию, которую мы внедрили: там и сам Трекер, и самописные решения, и связка с Google Таблицами, и внутренняя аналитика. В общем, «цифры, цифры, цифры», но руки до этой статьи пока не дошли.

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

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

Уведомление исполнителя об активации задачи

У нас довольно много задач в статусе «Отложено» — это своеобразный бэклог. Они ждут своего часа. Чтобы не теряться в этом потоке, мы сделали так: как только автор активирует задачу, триггер автоматически упоминает исполнителя в комментарии, чтобы тот точно не пропустил новую работу.

Уведомление автора о готовности задачи

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

Уведомление QA

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

Просроченные задачи

Мы больше работаем со списками, чем с канбаном. Но в Яндекс.Трекере, в отличие от Битрикса или Wrike, просроченные задачи в списке ничем не выделяются. Чтобы решить этот момент, у нас настроен триггер, который проверяет дедлайны. Если задача просрочена, в ней автоматически появляется комментарий с упоминанием автора и исполнителя: «Ребята, тут что-то не так».

Подсчет возвратов на доработку

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

Автоматическая очистка поля «Ждёт ответа»

В Трекере есть специальное поле — своего рода флажок «ждём ответа от пользователя». Но если задача закрыта и полностью готова, понятно, что никаких ответов уже не требуется. Поэтому при закрытии задача автоматически очищается от этого флажка.

Очистка дат при переходе в «Отложено»

Если задача по каким-то причинам откладывается после полного цикла работы (например, требует доп. согласований), у неё обычно остаются заполненные даты начала и дедлайна. Чтобы не возникало путаницы, при переводе в статус «Отложено» все даты автоматически обнуляются. Этот статус у нас своего рода «бутылочное горлышко»: если задачу решат активировать заново, через него точно пройдут.

Оценка задач

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

Сбор обратной связи: оценки автора и исполнителя

Мы внимательно следим за качеством процессов. Исполнитель может оценить постановку задачи по 5 параметрам по 5-балльной шкале. В свою очередь, автор задачи (менеджер или инициатор) оценивает исполнителя по аналогичным критериям. Эти данные идут в систему для последующего анализа.

Интеграция комментариев с Telegram

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

Учёт затрат времени

Все данные о потраченном времени, которые исполнители заносят в Трекер, автоматически передаются в нашу систему учёта. Про саму миграцию на этот подход и нюансы можно рассказать отдельно — это целая история.

Контроль невзятых задач

У нас есть промежуточный статус «Активно» — задача должна быть в работе. Но иногда исполнитель по каким-то причинам не приступает к ней вовремя. Если наступает дата начала задачи, а статус остаётся «Активно», система пишет комментарий: «Почему задача не в работе?». Это помогает авторам вовремя отреагировать.

Шаблон описания для задач

Чтобы все задачи были структурированными, мы используем шаблон описания. Автоматизация добавляет этот шаблон в тело задачи при создании.

Назначение QA-наблюдателя

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

Уведомление о перерасходе времени

С переходом на учёт времени мы стали следить за тем, чтобы задачи укладывались в оценку. В каждой задаче есть поле «Оценка» — например, 8 часов. Если исполнитель начинает выходить за рамки, появляется прогресс-бар. Чтобы автор был в курсе перерасхода, триггер шлёт уведомление: «Обрати внимание, задача выходит за пределы оценки». Всё это внедрено максимально лояльно, без излишнего контроля, но помогает следить за процессом.

P.S. Термины «Автор» и «Исполнитель» могут звучать сухо, но это стандартные обозначения из самого Яндекс.Трекера — так просто удобнее и привычнее.

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

Иллюзия коллективного выбора

Fri, 07 Mar 2025 08:34:04 +0300

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

Большинство, не задумываясь, ответит: «В демократическом». Это кажется естественным. Кто в здравом уме предпочтет авторитаризм?

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

Однако, если предложить этим же руководителям внедрить подобный подход в управлении их компаниями или отдела, реакция будет, мягко говоря, скептической. Демократия в бизнесе выглядит как минимум странно. Разве сотрудники в таких гигантах, как Apple, Google или Microsoft, выбирают себе начальников? Существует ли в Coca-Cola день всеобщего голосования? Слышали ли вы о внутрикорпоративных выборах в McDonald’s или IBM? А ведь именно эти компании считаются эталонами успеха и эффективности.

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

Интересно, что в книгах опытных управленцев, посвященных преодолению кризисов, часто встречается фраза: «И тогда я решил, что моя команда должна быть в курсе происходящего и участвовать в принятии решений, поэтому я собрал всех вместе...» Но в обычной, стабильной ситуации руководители редко допускают подчиненных к серьезным решениям. Максимум, что возможно, — это иллюзия участия, когда сотрудники могут влиять на второстепенные вопросы, но ключевые решения остаются за руководством.

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

Молодое поколение (назовем их условно «поколение Z») часто этого не понимает. Они уверены, что их мнение должно быть учтено в любом вопросе, а их влияние — безгранично. Результат такого подхода — разочарование, конфликты в команде, стрессы и провалы проектов. Люди чувствуют себя недооцененными и обманутыми.

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

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

Длинные деньги в разработке или как использовать роадмап

Wed, 05 Feb 2025 10:56:40 +0300

На конференциях и вебинарах для агентств, можно услышать совет: «Работайте с длинными деньгами, отказывайтесь от фикс-прайса, переходите на T&M или ритейнер».

Наверное, в этом есть правда. Мы и сами еще не полностью освоили этот подход, но активно к нему движемся.

Споры о фикс-прайсе и T&M не утихают. С одной стороны, зайти к клиенту всегда проще с фиксированной ценой — это понятный и предсказуемый формат для заказчика. Но что будет дальше? Контракт может трансформироваться в T&M, ритейнер или даже аутстафф.

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

🎯При чем тут длина?

Выражение «длинные деньги» часто звучит на профильных конференциях, в видео и статьях. По сути, это долгосрочные контракты в формате T&M или его аналогов.

💭Как это работает?

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

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

📌Верный ответ — предлагать свои задачи.

Мы стремимся работать так, чтобы у проекта всегда был краткосрочный план, проще говоря, бэклог задач. Помимо этого, формируем роадмап — стратегическое видение развития проекта.

📊Как мы формируем бэклог?

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

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

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

И так список

Roadmap

Когда

В конце текущего года — начале следующего подготовить годовой roadmap для каждого проекта.

Формат

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

Зачем

Главная цель — сформировать согласованный план по проектам на следующий период.

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

Возможные задачи

Перевод авторизации на одноразовые пароли на email
Редизайн
Оптимизация скорости сайта
Внедрение поиска Эластик или аналоги
Ускорение стабилизация обменов 1С или других систем
Создание отдельного нового фронта на vue или мобильное приложение
Личный кабинет физ лица
Личный кабинет юр лица

Документооборот, счета, акты, сверки
Чаты с менеджером
Персональные скидки
Рекламации

Добавление новых поставщиков на сайт
Интеграция с маркеплейсами / кейс Камы
Работа с почтовыми системами
Внедрение регулярной рассылки на основе данных сайта
Внедрение триггерных писем
Двусторонний обмен с CRM системой
Новые платежные системы + рассрочка + долями
Новые транспортные компании
Обогащение сайта контентом через парсер или руками
Улучшение адаптивности сайта для мобильных устройств.
Разработка системы рекомендаций для пользователей.
Автоматизация обработки заказов (сборка, отправка уведомлений и т. д.).
Внедрение системы аналитики пользовательского поведения (например, Google Analytics 4).
Разработка отдельного интефейса аналитики заказов, сбор рекламных расходов — кейс Кинга
Создание и запуск программы лояльности.
Интеграция системы учета бонусов и скидок.
Разработка функционала расчета стоимости доставки в режиме реального времени.
Интеграция с системами онлайн-консультантов (чат-боты, поддержка).
Обновление текущей платформы CMS или Laravel или VUE
Улучшение структуры каталога товаров.
Внедрение механизма upsell и cross-sell на сайте.
Автоматизация обработки возвратов и претензий.
Настройка push-уведомлений для мобильных пользователей.
Разработка механизма умного фильтра товаров
Внедрение работы с Четным знаком
Внедрение поддержки мультиязычного интерфейса сайта.
Автоматизация формирования отчетов по продажам и клиентам.
Интеграция с системой управления складом (WMS) или PIM системами
Добавление функционала предзаказов.
Внедрение генерации счетов и других документов на сайте.
Разработка функционала для создания и редактирования коммерческих предложений.
Оптимизация SEO для улучшения видимости сайта в поисковых системах.
Внедрение системы A/B тестирования для маркетинговых гипотез.
Реализация видеообзоров товаров.
Настройка логики автоматического скрытия товаров с нулевым остатком.
Добавление возможности самовывоза с выбором времени.
Разработка функции персонализированных скидок и акций.
Создание отдельного портала для партнеров или дистрибьюторов.
Внедрение системы контроля качества отзывов.
Улучшение безопасности сайта (например, двухфакторная аутентификация).
Реализация графического конфигуратора товаров (например, выбор цвета, размера).
Внедрение системы автоматического расчета оптовых цен
Разработка функционала сравнения товаров
Интеграция с системами электронного документооборота (EDI)
Создание мобильного приложения для курьеров/менеджеров
Автоматизация процесса формирования прайс-листов для разных категорий клиентов
Разработка системы учета и контроля маркетинговых активностей
Внедрение функционала «Избранные товары» с уведомлениями о изменении цен
Создание системы автоматического распределения заказов между складами
Создание функционала для работы с подарочными сертификатами
Внедрение функционала «Часто задаваемые вопросы» с базой знаний
Внедрение системы автоматического резервирования товаров
Создание системы автоматической генерации PDF-каталогов
Разработка модуля для работы с товарными остатками поставщиков
Создание функционала для работы с сезонными коллекциями
Внедрение функционала для работы с пакетными предложениями

Про пилотаж на собеседовании

Wed, 22 Jan 2025 08:29:28 +0300

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

Сегодня поговорим о том, как трансформировать стандартный опросник в увлекательный кейс.

Данный текст является продолжении рубрики про собеседования.

Оцифровываем процесс адаптации на коленке https://alexeyit.ru/all/kak-sdelat-onbording/
Собеседование не горит — дожми пользу по максимуму https://alexeyit.ru/all/sobesedovanie-ne-gorit/

В техническом собеседовании, особенно с программистами, кандидаты часто пытаются использовать внешние подсказки. Самые очевидные признаки — это поиск ответов на экране ноутбука или использование голосовых подсказок через наушник. С развитием технологий ИИ появились более изощренные способы, например, сервисы, работающие как телесуфлер и анализирующие вопросы через входящий аудиопоток — пример: TalkEze.

Live-кодинг: преимущества и ограничения

Для программистов очевидным решением становится live-кодинг — написание кода в реальном времени. Этот метод действительно эффективен, но имеет свои недостатки.

Во-первых, он требует дополнительных ресурсов от компании.

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

Игровые кейсы или метод кейс-интервью

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

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

Главное преимущество кейс-интервью заключается в его многогранности – один хорошо составленный кейс может раскрыть сразу несколько компетенций кандидата: от технических знаний до soft skills. При этом важно, чтобы сложность и контекст кейса соответствовали уровню позиции и специфике будущей работы кандидата.

Пример трансформации вопроса

Вместо прямого вопроса «Какие методологии разработки вы знаете?» можно создать ситуацию:

«Представьте: к вам пришел заказчик для разработки новостного портала. У вас уже есть предварительная договоренность по срокам и бюджету. Заказчик спрашивает про методологии разработки — он слышал про водопад, скрам, фикс прайс, агайл и Time&Materials. Как вы построите диалог и какое решение предложите?»

Такой формат позволяет оценить сразу несколько компетенций: знание методологий, клиентоориентированность, навыки коммуникации и принятия решений.

Можно развивать сценарий далее продолжив кейс, добавляя новые вводные: «Проект идет по скраму и Time&Materials уже 4 месяца из запланированных 5, и команда сообщает о необходимости дополнительных двух месяцев. Ваши действия? Как можно было предотвратить такую ситуацию?»

Примеры мини-кейсов

Frontend-разработчик

«Наш клиент — крупный интернет-магазин одежды. Пользователи жалуются на медленную загрузку страницы каталога, особенно при фильтрации товаров. На странице отображается сетка из 50 карточек товаров с изображениями, ценами и описаниями. Также есть панель с 15 различными фильтрами. Как бы вы подошли к оптимизации производительности? Какие метрики будете отслеживать?»

Backend-разработчик

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

DevOps-инженер

«В пятницу вечером произошел сбой в production-среде: основное приложение перестало отвечать на запросы, а мониторинг показывает загрузку CPU 100% на всех серверах. Команда разработки недоступна до понедельника. Опишите ваши действия по диагностике и решению проблемы. Как предотвратить подобные ситуации в будущем?»

UI/UX-дизайнер

«Мы разрабатываем мобильное приложение для пожилых людей (65+) по заказу службы доставки продуктов. Основные функции: выбор товаров, формирование корзины, оформление заказа и отслеживание доставки. Как бы вы подошли к разработке интерфейса? Какие особенности целевой аудитории учтете? Покажите на примере экрана каталога товаров.»

Бизнес-аналитик

«После запуска новой программы лояльности в нашей сети кофеен средний чек вырос на 20%, но общее количество транзакций упало на 15%. Какие данные вы запросите для анализа ситуации? Как определите причины изменений? Какие рекомендации могли бы дать бизнесу?»

QA-инженер

«Мы выпускаем крупное обновление платежной системы через неделю. В обновлении: новый платежный провайдер, поддержка Apple/Google Pay и автоматическое сохранение карт. Как построите процесс тестирования? Какие виды тестов включите? На что обратите особое внимание? Распишите приоритеты и примерный тайминг.»

Битрикс24

«Крупная строительная компания хочет автоматизировать процесс согласования договоров. Сейчас документы согласовываются через почту, а статусы отслеживаются в Excel. В процессе участвуют: менеджер по работе с клиентами, юрист, финансовый директор и генеральный директор. Как бы вы реализовали этот процесс в Битрикс24? Какие бизнес-процессы настроите? Как организуете хранение и версионность документов? Какие роли и права доступа предусмотрите?»

Менеджер проектов

«К вам обратился клиент из сферы e-commerce с задачей обновить их интернет-магазин. Текущая версия сайта работает на устаревшей версии 1С-Битрикс, дизайн не адаптирован под мобильные устройства, а функционал личного кабинета вызывает много нареканий у пользователей. Бюджет ограничен, сроки поджимают (нужно успеть к высокому сезону через 4 месяца). Как построите диалог с клиентом? Какую стратегию реализации предложите? Как организуете работу команды?»

Менеджер по продажам

«Вы работаете в компании, которая предоставляет услуги по разработке и внедрению CRM-систем. К вам поступил лид – небольшая торговая компания (30 сотрудников), которая использует Excel и WhatsApp для работы с клиентами. Они слышали про CRM, но не уверены в необходимости внедрения. У них ограниченный бюджет, и руководитель сомневается в окупаемости инвестиций. Как проведете первую встречу? Какие вопросы зададите? Как будете считать и презентовать выгоды от внедрения?»

И при чем тут пилотаж?

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

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

Адаптируйте кейс под опыт кандидата. Если он работал в e-commerce, используйте примеры из этой сферы.
Будьте готовы вернуться к классическому формату, если видите, что кандидат теряется в игровом сценарии.
Учитывайте уровень специалиста. Описанный формат лучше всего работает с кандидатами уровня middle и выше.

Почему ваш список дел — не ваш?

Tue, 14 Jan 2025 08:24:56 +0300

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

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

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

Любая методика тайм-менеджмента работает эффективно лишь до того момента, пока мы не осознаем этот фундаментальный факт. Человек, скрупулёзно расставляющий приоритеты в своём списке задач, напоминает школьника, решающего извечный вопрос: что делать сначала – математику или русский язык? В конечном итоге придётся выполнить все задания, иначе неизбежны негативные последствия.

В современных реалиях вся истинная приоритизация сводится к одному ключевому вопросу: «Какие последствия наступят, если я не выполню эту задачу?» Именно ответ на него определяет реальную важность дела, независимо от наших личных предпочтений.

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

Лучший фильм об управлении проектами или история, как успешный проект становится провалом

Fri, 10 Jan 2025 10:02:11 +0300

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

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

Сюжет

Биржевые маклеры Винсент и Антон Залевски решают реализовать идею в области высокочастотного трейдинга. Они собираются проложить кабель для передачи данных между Канзасской и Нью-Йоркской биржами, обеспечивающий минимальное время задержки. Тогда у них будет конкурентное преимущество. Для этого кабель должен быть проложен по кратчайшему маршруту.

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

Реальная история

Это прекрасная история о двух русских, которые затеяли высокотехнологичный стартап, в фильме использована история с Сергеем Алейниковым и Goldman Sachs только в других именах.

В фильме строили прямой тоннель из Канзаса в Нью-Йорк и хотели получить RTT 16 миллисекунд, а в реалии Spread Newtorks строили тоннель из шт. Нью-Джерси в г. Чикаго с RTT 13.1 миллисекунд.

Почему по прямой? Здесь вступают в игру Эйнштейн, теория относительности, скорость света и инженерия. Если вы помните цифры latency, за 1 миллисекунду свет проходит 300 км., т. е. считайте, что лишние 300 км кабеля добавляют к вашей линии 1 миллисекунду задержки.

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

Еще быстрее? Если по кабелю свет идет медленнее, чем скорость света, нельзя ли обойтись вообще без кабеля? Можно. В фильме упоминаются СВЧ-вышки (обещающие 14 миллисекунд между Канзасом и Нью-Йорком, а потом уже вообще — 11 миллисекунд) и даже лазерные башни.

Вокруг этого и строится весь сюжет.

Но это не так важно

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

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

Он раскрывает важную истину: успешное завершение проекта вовсе не гарантирует успеха самого продукта — и это то, чего многие менеджеры не осознают.

Этот фильм — о цене успеха, о том, на что готовы люди ради достижения цели, и о том, как, сделав все правильно, можно все равно проиграть.

Непременно смотреть всем, кто связан с управлением проектами.

Как сделать онбординг. На коленке, но с геймификацией

Thu, 26 Dec 2024 08:33:14 +0300

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

Что такое онбординг и почему он важен

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

Традиционно этот процесс выглядел достаточно стандартно: многочасовые презентации от HR-отдела, объемные инструкции, подробные рассказы наставников. Казалось бы, все вовлечены, все стараются. Но статистика неутешительна: при таком подходе человек запоминает едва ли 10% информации. Более того, даже инструкция «внимательно прочитай документацию в Вики» не работает — сотрудники чаще всего просто бегло просматривают документы.

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

Поиск решения

Перед нами стояла задача: создать онбординг, который будет не только информативным, но и увлекательным. Мы рассмотрели несколько вариантов:

Первый — использовать готовое платное решение вроде Потока. Красиво, функционально, но требует существенных финансовых вложений и глубокой интеграции.

Второй — разработка собственной системы с нуля, что потребует значительных временных и человеческих ресурсов.

Третий — поиск сервиса, который легко интегрируется с существующей инфраструктурой.

В итоге мы остановились на решении — Яндекс.Формах. Казалось бы, странный выбор, но именно этот сервис позволил нам реализовать нашу концепцию максимально просто. Плюс система уже интегрирована в Трекером, что в нашем случае очень удобно.

Архитектура нашего онбординга

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

Каждый шаг представлен в виде интерактивной формы, где информация подается порционно — экранами.

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

Второй этап посвящен погружению в рабочие инструменты. Основной акцент — изучение Яндекс.Трекера, понимание системы проектов и задач. Здесь же происходит первичная его настройка. Да, для Яндекс Трекера нужен мануал чтобы туда попасть.

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

Четвертый этап — персонализация. В зависимости от отдела и направления деятельности сотрудник получает индивидуальную траекторию адаптации.

Это “костыльное” решение, чтобы направить человека далее на нужный шаг далее.

Четвертый продолжение, заключительный этап, — профессиональная специализация. Для технических специалистов это детальное погружение в профессиональные инструменты: git, IDE, системы разработки, фреймворки.

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

Далее разветвление по направлениям. Яндекс Формы поддерживают функционал проверок предыдущих ответов и дальнейший текст можно посвятить конкретному направлению, например фронтенду и его специфике.

Ну и уже детали по направлению

Управление и минусы

Яндекс.Формы предоставляют неожиданно удобный инструментарий. Поддержка Markdown позволяет создавать структурированный контент, простой редактор и drag-and-drop механика существенно упрощают настройку.

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

Для мониторинга процесса прохождения мы сделали в Трекере отдельную очередь. Каждый их этапов создает задачу в трекере, что дает HR-отделу полную картину прогресса каждого нового сотрудника.

Результаты и перспективы

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

В планах — продолжение развития системы, добавление более сложных механик тестирования и оценки знаний. Главное — мы создали живой, адаптивный инструмент, который может трансформироваться вместе с потребностями компании.

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

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

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

Sun, 08 Dec 2024 08:49:38 +0300

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

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

Этот подход понятен, но я придерживаюсь другой стратегии. Для себя я решил доводить каждое собеседование до конца — и вот почему.

Я искренне люблю знакомиться с новыми людьми. Пусть это происходит в такой специфической/странной форме, как собеседование, но это всё равно ценный опыт общения.
Если ещё в начале или середине собеседования становится ясно, что кандидат не наш, я сворачиваю техническую часть и перехожу к «продаже».

Как извлечь максимум пользы из собеседования?

Конечно же, себя. Я стараюсь максимально подробно рассказать о нашей компании:

какие кейсы мы решаем
в чём наша ценность для клиентов
как устроены наши процессы и с кем мы работаем
какая у нас команда

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

Почему важно рассказывать о компании даже неподходящим кандидатам?

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

Обмен опытом на собеседовании: как найти скрытые инсайты

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

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

Резюме: собеседование как долгосрочная инвестиция

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

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

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

Раз уж время уже выделено, почему бы не сделать из собеседования полезную инвестицию в будущее?

Чем кормить менеджеров?

Thu, 05 Dec 2024 09:34:49 +0300

Назрел вопрос о людях, управляющих проектам в продакшен-агентствах с fixprice и/или t&m.

Далее буду использовать аббревиатуры из классического треугольника Sales-PM-Account. Sale не рассматриваем.

PM или менеджер проекта. Отвечает за производство проекта, контролирует сроки, цену, качество.
Account или менеджер по работе с клиентами. Осуществляет клиентский сервис, развивает стратегические отношения с клиентом, реагирует на рекламации, старается, чтобы на всем этапе существования клиента в компании ему было комфортно и легко.

Описание с habr — спасибо Андрею Терехову и Алексею Раменском за наводку

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

Роль PM и Account совмещены в одном человеке (иногда их называют продюсерами)
второй вариант — два человека, отвечающие за свою роль, и иногда Account еще выполняет sales-функции.

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

У продюсера встает вопрос о нагрузке и выгорании. Выгорание, по нашей статистике, наступает примерно за 1—2 года. Далее приходится либо искать новых людей и обучать, что тоже сомнительно и требует времени. Либо работать с мотивацией своих менеджеров.

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

KPI может не очень хорошо работать в некоторых комбинациях PM + Account, так как менеджер может только косвенно влиять на эти показатели (да, тут проблема плохих KPI, но все же). Проблема у схемы % с оборота — то пусто, то густо.

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

Решение?

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

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

Что такое OKR? Система, методология для постановки целей?

Mon, 25 Nov 2024 11:26:34 +0300

Уже давно задумываемся о внедрении OKR, KPI или другого инструмента для повышения эффективности работы. Постепенно изучаем материалы на эту тему.

Агентский бизнес, на первый взгляд, не очень хорошо сочетается с OKR, но ребята из Agima показали отличный пример их успешного применения: четкая структура, ясные цели и задачи. Единственное, что вызывает вопросы, — это используемый инструмент. Это снова Google Таблицы, которых и так хватает.

У Яндекса есть интересный материал о внедрении OKR, и на скриншотах виден специализированный инструмент. До недавнего времени его не было в Яндекс.Трекере, но теперь функционал «Целей / OKR» доступен в экспериментальном режиме. Воодушевившись, решили погрузиться в тему еще глубже.

Текст ниже это перевод материала генерального директора Tability, Стена.

В статье рассматривается основные нюансы, необходимые для понимания методологии OKR и принципов её работы.

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

Давайте начнем!

Откуда появились OKR?

Аббревиатура OKR расшифровывается как Objectives and Key Results (Цели и Ключевые Результаты). История этой методологии постановки целей началась, когда Энди Гроув представил подход OKR в Intel в 70-х годах. Однако потребовалось еще около 30 лет, прежде чем методология получила широкое распространение — это произошло, когда Джон Дорр принес её в Google в 1999 году. Спустя еще 20 лет OKR уже не является процессом, зарезервированным только для крупных компаний. Сегодня мы видим, как множество стартапов и растущих компаний используют OKR для постановки амбициозных целей, выравнивания команд и ускорения пути к успеху.

Роль OKR: вектор в организации

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

Так для чего же тогда нужны OKR?

Основная цель методологии OKR — быть компасом для вашей организации.

Команды можно рассматривать как векторы, направляющие свои усилия в определенных направлениях:

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

Ваша команда продаж может работать с малым и средним бизнесом или корпоративным рынком — опять же, это два разных направления.

Ваша продуктовая команда может решить создавать корпоративные функции или заняться производительностью приложения...

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

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

Именно здесь появляются OKR. Главная задача методологии OKR — не оказывать давление на ваши команды. Она заключается в том, чтобы служить Полярной звездой для всех команд. За пределами амбициозных целей, цикла OKR, чек-инов и т. д., OKR предлагают единый язык для фокусировки, а также четкую структуру для согласования целей команды с целями компании.

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

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

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

OKR против стратегических инициатив (ваших проектов)

Распространенная ошибка при внедрении OKR — недостаточное время, уделенное определениям, прежде чем команда начнет использовать методологию.

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

«Моя цель — создать новый процесс онбординга»

«Мой ключевой результат? Обновить весь маркетинговый текст»

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

Так в чем же разница?

Вот простой способ понять, как различаются OKR и инициатив (или проектов):

Цели: где мы хотим быть в конце квартала? (направление)
Ключевой Результат: как мы будем измерять прогресс? (тяга)
Стратегические инициативы: какие наши лучшие ставки, чтобы туда попасть? (действие)

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

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

Другое ключевое различие заключается в том, насколько стабильным будет каждый элемент во время цикла OKR:

Цели должны быть твердыми: ваши Цели должны закреплять фокус ваших команд в течение квартала. И как таковые, они должны оставаться стабильными в течение цикла OKR.

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

Проекты — это ставки: наконец, большая разница между командами, ориентированными на выпуск, и командами, ориентированными на результат, заключается в том, что последние спокойно отбрасывают проекты. Они просто рассматривают их как ставки для достижения конкретных результатов.

Примеры хороших и плохих OKR

Мы рассмотрели много теории, так почему бы не взглянуть на некоторые конкретные примеры.

Вот некоторые характеристики хороших OKR:

Они понятны членам разных отделов.

Они избегают внутреннего жаргона и неизвестных аббревиатур.

Они измеримы и легко отслеживаются в течение квартала.

Они фокусируются на результатах и влиянии, а не на поставках и сроках.

Они не привязаны к компенсации.

Они повышают вовлеченность сотрудников.

Их немного!

Вот некоторые характеристики плохих OKR:

Они кажутся актуальными только для небольшой части организации.

Язык неоднозначный или труден для понимания.

Ключевые Результаты бинарны или прогресс трудно оценить.

Они выглядят как другое представление дорожной карты.

Они используются для управления эффективностью, а не для выравнивания команд.

Они подрывают моральный дух команды.

Их слишком много!

Ниже вы найдете пару примеров, иллюстрирующих разницу.

Пример 1: плохой OKR, сфокусированный на инициативе

Продуктовая команда проводила бета-тестирование в течение последних 6 месяцев. Их пользователи довольны, продукт достиг зрелости, и продуктовая команда решила, что они могут начать выставлять счета своим клиентам. Они определили Stripe как лучшее решение для обработки подписок.

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

Цель: Создать интеграцию со Stripe для начала выставления счетов нашим клиентам
Ключевые Результаты: ?
Проекты: ?

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

Но мы можем добраться до Цели, спрашивая *почему* мы работаем над выходом:

В: Почему мы хотим интегрироваться со Stripe?
О: Чтобы пользователи могли подписываться онлайн.
В: Почему мы хотим, чтобы пользователи подписывались онлайн?
О: Чтобы иметь платящих клиентов!

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

Пример 2: хороший OKR, сфокусированный на влиянии

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

Есть заметные различия с нашими новыми OKR:

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

Простая формула для написания отличных OKR

Джон Дорр предложил простую формулу для написания OKR.

«Я буду [описание цели], что будет измеряться [детали ключевых результатов].»

Первый пропуск представляет собой Цель, а второй пропуск касается соответствующих Ключевых Результатов. Это отличный способ разделить качественный аспект Цели от количественной функции Ключевых Результатов.

Советы по написанию хороших Целей

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

Сделайте это предложением

Не пишите «Удержание» как цель компании. Это не вдохновляет и может привести к плохой тактике, например, к удалению возможности отмены подписки в приложении. Вместо этого следует написать «Обеспечить потрясающий опыт для недавно привлеченных клиентов». Это утверждение касается удержания, но уточняет, на каком сегменте нужно сфокусироваться и как мы хотим достичь большего удержания.

По возможности избегайте метрик

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

Вместо того чтобы писать «Продать 50 крупных контрактов» (привлекательно для продаж), мы могли бы написать «Произвести впечатление на компании из Fortune 500» (близко многим командам). Затем мы можем перечислить количество закрытых сделок в ключевых результатах, а также иметь другие цели, связанные с готовностью продукта к корпоративному сегменту.

Будьте конкретны

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

Советы по написанию хороших Ключевых Результатов

Хорошие Ключевые Результаты помогут вам измерить прогресс в достижении целей компании или команды. Простой способ написать хорошие Ключевые Результаты — это использовать методологию SMART для ваших целей. Эта методология поможет вам убедиться, что вы учли все необходимые аспекты хорошего Ключевого Результата, включая его достижимость и ограниченность по времени.

Вот еще несколько полезных советов:

У Ключевых Результатов должен быть владелец. Его задача — отслеживать прогресс и делиться обратной связью с организацией.
Ключевые Результаты не должны быть бинарными. Будет сложно оценить прогресс, если вы не можете измерять его с течением времени.
Используйте опережающие индикаторы успеха для долгосрочных проектов. Не ждите выпуска проекта, чтобы начать формировать уверенность в результатах.

Как объяснить преимущества OKR

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

Преимущество OKR #1: Лучшая видимость прогресса между командами

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

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

Плохое исполнение приведет к недостижению целей. Недостижение целей подорвет моральный дух.

Внедрение OKR — это простой способ решить эту проблему. Оно обеспечивает использование общих терминов и упрощает обсуждения. Вы можете переходить от одной команды к другой и задавать одни и те же вопросы до и во время цикла OKR:

Каковы ваши Цели?
Каковы ваши Ключевые Результаты?
Связан ли ваш проект с существующим Ключевым Результатом?
Идут ли ваши OKR по плану?

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

Преимущество OKR #2: Более простое согласование

«OKR не каскадируются» — Фелипе Кастро

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

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

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

При правильном подходе OKR значительно помогут вам улучшить согласованность и помочь всем принимать лучшие решения в повседневной деятельности.

Преимущество OKR #3: Улучшенная фокусировка — всегда помните о главном

OKR улучшают фокус, ограничивая набор конкурирующих приоритетов. В этом руководстве мы рекомендуем начать с матрицы 3x3:

3 Цели

3 Ключевых Результата на каждую Цель

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

Другой способ, которым процесс OKR может улучшить фокус — это действовать как периодическое напоминание о том, что важно. Когда вы сочетаете систему постановки целей с еженедельным отслеживанием целей, членам команды становится действительно легко держать в уме свои главные приоритеты.

Каждое обсуждение проекта происходит с правильным контекстом.

Преимущество OKR #4: Повышенная ответственность

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

Ответственность — это не о контроле за людьми. Это о приверженности нашим целям и честности в оценке нашей способности их достичь.

Преимущество OKR #5: Создание по-настоящему уполномоченных команд

«Мы хотим убедиться, что каждый член команды присоединился к ней, потому что искренне верит в нашу более широкую цель.» — Марти Каган в «Уполномоченные продуктовые команды»

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

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

Как оценивать OKR — и почему не стоит копировать Google

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

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

Советы по оценке ваших OKR:

Придерживайтесь той же шкалы оценок, которую вы используете для других KPI. Если вы празднуете достижения в районе 80-100%, то применяйте те же ожидания к вашим OKR.

Отслеживайте прогресс каждую неделю. Еженедельная оценка ваших OKR поможет вам выявить проблемы на раннем этапе.

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

Сравнение OKR с другими системами постановки целей

В этом разделе мы рассмотрим некоторые классические альтернативы OKR. В Tability мы рекомендуем OKR как первый вариант, но есть много других доступных опций, если вы чувствуете, что OKR не для вас. Возможно, вы ищете более полную систему, как Scaling Up, или другой подход, как NCT.

OKR против KPI

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

OKR против MBO

Управление по целям (MBO) было популяризировано Питером Друкером в 1954 году. Это процесс, в котором менеджеры и сотрудники согласовывают конкретные цели производительности и разрабатывают план их достижения. Большая часть MBO — это постоянное измерение и мониторинг производительности сотрудников относительно целей.

OKR против NCT

Нарративы, Обязательства и Задачи (NCT) — это еще одна система постановки целей, созданная Reforge. Нарративы — это более проработанная версия Целей. Это качественное описание того, чего команда хочет достичь, и часто может быть написано в виде пары предложений. Обязательства эквивалентны Ключевым Результатам — это объективно измеримые цели, которые относятся к конкретному Нарративу. Задачи помогают вам изложить работу, которую необходимо выполнить для достижения Обязательств.

OKRs против Scaling Up

Scaling Up — это фреймворк, который был представлен в 2002 году Верном Харнишем. Он построен на основе привычек Рокфеллера и представляет собой полный набор процессов и действий для превращения стратегии в конкретные задачи. Метод Scaling Up включает множество элементов из существующих практик и может рассматриваться скорее как способ управления компанией, чем просто фреймворк для постановки целей командам.

OKRs против BHAG

BHAG — это концепция, разработанная Джимом Коллинзом в его книге «Построено навечно». Большая волосатая амбициозная цель (Big Hairy Audacious Goal, BHAG) — это четкое и убедительное утверждение, которое ставит амбициозную цель для команды. Лучший пример этого — миссия NASA высадить человека на Луну и безопасно вернуть его на Землю. BHAG обычно рассматривает долгосрочное видение, но при этом также создает сильное чувство срочности.

OKRs против SMART-целей

SMART — это аббревиатура, которая означает Specific (конкретный), Measurable (измеримый), Achievable (достижимый), Relevant (актуальный) и Time-Bound (ограниченный по времени). Это скорее набор рекомендаций по написанию профессиональных целей, чем фреймворк постановки целей как таковой. На самом деле мы рекомендуем использовать метод SMART-целей для написания ваших ключевых результатов, так как это облегчает задачу выражения ключевых результатов в виде измеримых результатов.

Нужно ли использовать программное обеспечение для OKR? Нет, потом да.

Мы рассмотрели большинство вещей, которые вам нужно знать, чтобы начать работу с OKR. Остался последний вопрос, на который нужно ответить перед тем, как мы закончим: *стоит ли использовать специализированную платформу или нет?*

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

Простой электронной таблицы будет достаточно на первый квартал.

А после этого? Специализированный инструмент легко удвоит или утроит преимущества.

Для эффективной работы OKR вам нужно несколько вещей:

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

Платформа вроде Tability может сократить время, затрачиваемое на отчетность, на 80%, предлагая при этом автоматизированные панели мониторинга и множество способов связать ваши цели с существующими инструментами.

Такие инструменты, как Github, Canva, Jira, сделали совместную работу над кодом, дизайном и проектами намного проще и продуктивнее. То же самое будет относиться к Tability и целям.

Подводя итоги: 10 распространенных ошибок, которых следует избегать

Хорошо, еще одна вещь! OKR — это сложно, но в конце есть реальная отдача. При этом вам не нужно повторять ошибки, через которые прошли другие люди.

Вот список распространенных подводных камней, которых следует избегать на вашем пути с OKR:

Слишком много OKR: начните просто с 3 целей и 3 ключевых результатов для каждой цели.

Превращение дорожной карты в OKR: не пытайтесь зафиксировать все, что вы делаете, как ключевой результат.

Отсутствие владельцев ключевых результатов: OKR не будут работать, если никто не несет за них ответственность.

Наличие только одного владельца для всех ключевых результатов: распределите владение ключевыми результатами между командами. Никто не должен обновлять более 7 пунктов каждую неделю.

Отсутствие отслеживания прогресса: OKR без отслеживания целей — это просто отчетность. OKR должны помогать принимать лучшие решения каждую неделю.

Отслеживание обычной деятельности с помощью OKR: обычная деятельность все равно должна происходить! Не нужно создавать для нее OKR, вы можете просто разделить свои усилия между 70% OKR и 30% обычной деятельности.

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

Излишняя реактивность: не паникуйте, если ваши OKR внезапно оказались в красной зоне. Подождите пару недель, чтобы увидеть, был ли это временный сбой или тенденция.

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

Отсутствие расширения прав и возможностей команд: OKR могут работать только если люди имеют полномочия действовать. Убедитесь, что у вас есть правильная культура для поддержки этого фреймворка.

Fixed Price, T&M или Retainer: как выбрать идеальный подход в IT-разработке

Fri, 08 Nov 2024 16:02:48 +0300

По мотивам предыдущего материала, остановили мы свой выбор на аутсорсинговой модели.
Однако здесь мы сталкиваемся с новым выбором — существует несколько разновидностей данной модели. Наиболее распространены три из них: T&M (Time & Materials, или «время и материалы»), Retainer (ритейнер) и fix price или классический договор с ТЗ и водопадной моделью.

После 10 лет работы в IT-разработке я понял одну простую истину: выбор типа договора — это как выбор любимого цвета фломастеров. Вроде бы всё просто, но почему-то все нервничают и часто остаются недовольны результатом. Расскажу о своей практике, и почему каждый из типов может быть как благословением, так и проклятием.

Fixed Price: Заблуждения и суровая реальность

А, Fixed Price — любимец всех заказчиков и головная боль разработчиков. Помню свой первый такой проект: клиент пришел с «простым сайтом», который превратился в многостраничный портал с горой функцией и заказом.

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

Что такое Fixed Price на самом деле?

Если совсем просто: это когда вы договариваетесь о цене заранее, и она не меняется. Звучит прекрасно, правда? Как в супермаркете: пришел, увидел ценник, купил. Но в реальности это больше похоже на покупку кота в мешке — для обеих сторон.

Плюсы (которые не всегда плюсы):

Вы точно знаете, сколько заплатите. Правда, возможно, придется доплачивать за каждый чих, не описанный в ТЗ
Сроки фиксированные. Ну, как фиксированные... давайте скажем, «предположительно фиксированные»
Все описано в ТЗ. Которое никто никогда не читает полностью, кроме юристов при возникновении споров

Минусы (они же суровая реальность):

Хотите изменить цвет кнопки? Готовьте дополнительное соглашение и новый бюджет
Цена обычно выше, потому что мы, разработчики, не экстрасенсы и закладываем в стоимость все возможные риски, включая падение метеорита
ТЗ может устареть еще до того, как вы закончите его читать

Time & Materials: Гибкость или бесконечность?

T&M — это как счетчик в такси. Едем столько, сколько нужно, платим за реальное время. Звучит справедливо, да? Но попробуйте объяснить клиенту, почему простая функция поиска заняла 40 часов разработки...

T&M идеально работает, если заказчик понимает ценность гибкости. Например, в стартапах, где гипотезы проверяются на лету, или в проектах с инновационными технологиями. Но важно учитывать, что отсутствие четкого плана может привести к перерасходу бюджета. Чтобы этого избежать, советуем обсуждать ожидаемые объемы работы с разработчиками на каждом этапе.

Почему это часто работает лучше:

Можно начать работу, даже если вы еще не уверены, чего именно хотите
Гибкость уровня «мастер йоги» — меняйте требования хоть каждый день
Прозрачность как у горного ручья — вы видите, за что платите

Подводные камни:

Бюджет может растянуться как резиновый
Сроки? Какие сроки? Мы работаем в agile!
Заказчику нужно быть готовым к активному участию в процессе

Retainer: Абонемент на разработку — плюсы и минусы

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

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

Почему это может быть круто:

Команда погружается в проект как рыба в воду
Не нужно каждый раз объяснять, почему у вас база данных называется «Петрович»
Можно работать в режиме «а давайте попробуем вот это»

Почему это может быть не очень:

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

Как выбрать подходящий тип договора для вашего проекта?

После стольких лет в индустрии я пришел к простому правилу: выбирайте договор как партнера для танцев — по ситуации и уровню доверия.

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

Fixed Price подойдет если:

Вы точно знаете, чего хотите (да-да, я тоже так думал)
У вас есть четкое ТЗ, которое не изменится по щелчку пальцев директора
Проект небольшой и понятный, как табуретка

Time & Materials — ваш выбор, когда:

Вы готовы к приключениям и неожиданным поворотам
Требования могут меняться чаще, чем погода в Петербурге
Вы верите в честность и прозрачность (и готовы за это платить)

Retainer стоит рассмотреть если:

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

Итоги: как избежать ошибок при выборе

В конце концов, выбор типа договора — это как выбор между макаронами и пиццей на ужин. Нет правильного ответа, есть только то, что подходит именно вам в данный момент.

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

Мой главный совет: не бойтесь обсуждать все нюансы заранее. Лучше потратить лишний час на обсуждение условий договора, чем потом месяцами переписывать ТЗ или спорить о счетах.

И помните: какой бы тип договора вы ни выбрали, всегда найдется клиент, который скажет: «А вот мой друг сделал такой же проект в два раза дешевле». Но это уже совсем другая история...

Аутстаффинг и Аутсорсинг в IT: что выбрать?

Thu, 31 Oct 2024 15:34:21 +0300

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

Что такое аутстаффинг?

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

Плюсы аутстаффинга:

Гибкость в управлении — вы напрямую контролируете процесс работы специалиста
Быстрое масштабирование команды — можно оперативно привлечь нужных специалистов
Экономия на HR и бухгалтерии — всю кадровую работу берет на себя провайдер
Снижение юридических рисков — трудовые отношения оформляет компания-провайдер
Возможность подбора конкретных специалистов под ваши требования

Минусы аутстаффинга:

Необходимость собственного управления — требуется опытный менеджмент для координации работы
Риски неэффективного управления — без правильного менеджмента производительность может падать
Затраты на организацию процессов — нужно выстраивать внутренние процессы и коммуникации
Дополнительные расходы на менеджмент — возможно потребуется нанимать project/team lead
Сложности с интеграцией — могут возникнуть проблемы при встраивании специалиста в существующую команду

Что такое аутсорсинг?

Аутсорсинг подразумевает передачу определенных задач или целого проекта внешней компании, которая берет на себя полную ответственность за результат. В этом случае вы получаете не отдельных специалистов, а готовое решение «под ключ».

Плюсы аутсорсинга:

Готовая команда с менеджментом — не нужно выстраивать процессы управления
Гарантированный результат — компания-подрядчик несет ответственность за качество
Отлаженные процессы — команда уже имеет опыт совместной работы
Комплексный подход — все необходимые специалисты уже есть в команде
Снижение операционной нагрузки — не нужно погружаться в детали реализации

Минусы аутсорсинга:

Более высокая стоимость — в цену включен менеджмент и накладные расходы
Меньший контроль над процессом — нет прямого управления специалистами
Возможные задержки в коммуникации — необходимость общаться через менеджеров
Зависимость от подрядчика — сложнее сменить исполнителя
Риски утечки информации — доступ к проекту получает сторонняя компания

Важность менеджмента в IT-проектах

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

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

правильно ставить задачи
контролировать сроки
обеспечивать качество кода
управлять приоритетами
решать возникающие проблемы

работа может оказаться неэффективной. В результате приходится дополнительно нанимать team lead или project manager, что существенно увеличивает итоговый бюджет.

При аутсорсинге эта проблема решена изначально — в команде уже есть опытные менеджеры, знающие как организовать работу разработчиков максимально эффективно.

Особенности работы крупного бизнеса с IT-командами

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

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

Выбор модели сотрудничества в зависимости от масштаба бизнеса

Средний бизнес обычно выбирает более гибкие модели взаимодействия с внешними командами. Time & Materials и ретейнер становятся оптимальным выбором, поскольку позволяют оперативно регулировать объем привлекаемых ресурсов и быстро переориентировать команды на новые приоритеты.

Малый бизнес и стартапы чаще обращаются к модели Fixed Price. Это обусловлено потребностью в четком планировании бюджета и желанием минимизировать риски перерасхода средств.

Эволюция

Интересен типичный путь развития отношений между заказчиком и командой разработки. Часто сотрудничество начинается с тендера и контракта fix price на разработку конкретного проекта. После успешного завершения проекта и передачи его заказчику отношения часто трансформируются в более долгосрочное сотрудничество.

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

Общие выводы

Выбирайте аутстаффинг, если:

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

Выбирайте аутсорсинг, если:

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

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

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

Капитан Очевидность на мостике: управление временем для тех, кто его уже потерял

Tue, 29 Oct 2024 10:07:17 +0300

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

Как капитан, ваша задача — безопасно провести корабль к острову сокровищ, который символизирует вашу цель на день.

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

Что такое управление временем?

Управление временем похоже на видеоигру, где нужно выполнить задания до истечения времени.

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

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

Почему управление временем важно для менеджеров?

У менеджеров особая работа. Они должны обеспечить, чтобы команда была довольна, работа выполнялась качественно и все было сделано вовремя.

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

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

7 советов по управлению временем для менеджеров

1. Знайте, что нужно сделать

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

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

Мы любим думать, что наши списки дел эффективны, но в конце дня все равно чувствуем себя непродуктивными.

Принцип Парето, также известный как правило 80/20, гласит, что «20% ваших действий приносят 80% результатов». Другими словами, если у вас список из 10 дел, 2 из них будут стоить больше, чем остальные восемь.

Работа распределяется неравномерно, поэтому нужно сосредоточиться на том, что имеет наибольшее значение.

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

Вот как применить принцип 80/20 к вашему списку дел:

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

Оцените влияние. Теперь рассмотрите потенциальные положительные результаты от каждой задачи. Оцените таким же образом, где 10 — максимальное влияние

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

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

Другие, требующие больше усилий при малых результатах, можно отложить или убрать из списка дел.

2. Составляйте план на день

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

Каждое утро менеджеры должны составлять план того, что они хотят сделать за день.

Используйте технику тайм-блокинга.

Слышали об Илоне Маске, Билле Гейтсе или Кэле Ньюпорте?

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

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

Нужно добавить важный элемент: время.

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

Тайм-блокинг — это метод объединения управления задачами и календаря. Вы создаете «блоки» времени в своих днях и назначаете им задачи для концентрации. Каждая задача вписывается в свой временной блок, не прерывая ничего другого.

Вот как закрепить временные блоки:

Сделайте временные блоки заметными. Используйте яркие цвета или заголовки. Заблокированное время должно бросаться в глаза при взгляде на планировщик

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

Придерживайтесь плана. Сделайте это привычкой. Для этого придерживайтесь этих блоков как минимум 30 раз. Это станет ритмом вашей недели.

3. Разбивайте большие задачи на меньшие

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

Разбивайте задачи максимально подробно. Я предпочитаю задачи, которые можно выполнить менее чем за 90 минут.

Используйте технику Помодоро при работе над задачами. Помните мое предпочтение задачам, которые занимают менее 90 минут? Это 3 цикла Помодоро.

Разделение больших задач на меньшие помогает оставаться на правильном пути и дает чувство достижения при выполнении каждого пункта. Это также облегчает поддержание фокуса и обеспечивает стабильный прогресс в достижении целей проекта.

4. Выделяйте время для почты и встреч

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

Например:

Обработка почты — это просто еще одна задача (повторяющаяся). «Окна» для почты — это отрезки времени для обработки писем.

У меня есть три «окна» для пакетной обработки почты:

После выполнения самой важной задачи дня. Обычно это около 11 утра

После обеда. Уровень энергии немного ниже, поэтому это идеальное время для неглубокой работы

Перед окончанием рабочего дня. Это гарантирует, что ничего не упущено перед завершением работы

В течение этих окон я сосредотачиваюсь на выполнении 1 из 6 возможных действий с каждым сообщением:

Ответить. Если письмо требует немедленных действий и я могу ответить быстро

Архивировать. Если больше ничего делать не нужно

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

Добавить в менеджер задач. Когда письмо содержит задачу

Отправить в приложение для заметок. Для информации, которую хочу сохранить для будущего использования

Отправить в приложение «Прочитать позже». Для информации, которую хочу обработать позже

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

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

5. Учитесь говорить «нет»

Умение говорить «нет» — это навык. Мы начинаем с ограниченного опыта, но можем улучшить его со временем. В книге «Эссенциализм: Путь к простоте» Грег МакКеон предлагает семь эффективных способов сказать «нет»:

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

Мягкое «нет» (или «нет, но»). Объясните, что сейчас вы сосредоточены на других вещах, но будете рады встретиться, когда закончите с ними

«Дайте мне проверить календарь и вернуться к вам». Это даст вам время остановиться и оценить свои приоритеты. Верните контроль над своими решениями, вместо того чтобы спешить сказать «да»

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

Укажите, что вы готовы сделать: например: «Вы можете взять мою машину. Я готов обеспечить, чтобы ключи были здесь для вас». Делая это, вы также говорите, что не сможете подвезти человека, но формулируете это с точки зрения того, что вы готовы сделать

Я не могу это сделать, но X может быть заинтересован». Соблазнительно думать, что наша помощь уникально бесценна, но часто людям, запрашивающим что-то, все равно, кто им поможет — главное, чтобы они получили помощь

6. Делайте перерывы

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

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

Мы ассоциируем перерывы со временем, которое могли бы потратить на работу. Ничто не может быть дальше от истины.

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

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

Другими словами: Вашему мозгу нужен отдых между периодами сосредоточенной работы.

Я делаю два типа перерывов:

10-15 минутный перерыв, двигаюсь, иду за кофе и т. д.

Более длительный 20-30 минутный перерыв, когда я полностью отключаюсь от работы

7. Анализируйте свой день

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

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

Для моего ежедневного обзора я записываю 2-3 достижения дня. Это может быть что угодно:

Выполнение важной задачи

Получение нового клиента или проведение отличной встречи

Затем я проверяю свой календарь на следующий день и корректирую его при необходимости. Весь этот процесс занимает не более 5-10 минут.

Управление временем для менеджеров

Управление временем для менеджеров — это умение быть хорошим капитаном своего дня. Оно помогает выполнять работу, направлять команду и при этом находить время для отдыха.

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

Знайте, что нужно сделать. Расставляйте приоритеты в списке дел, используя принцип Парето

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

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

Выделяйте время для почты и встреч. Используйте «окна» для пакетной обработки почты

Учитесь говорить «нет». Используйте один из 7 эффективных способов сказать «нет»

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

Анализируйте свой день. Записывайте 2-3 достижения дня

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

Оценка задач: таинственное искусство

Thu, 10 Oct 2024 16:16:11 +0300

«Ты видел их оценки для этой работы?» — спрашивает меня один из коллег.

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

Я пытаюсь быть дипломатичным. «Похоже, что эти оценки были намеренно увеличены из-за страха перед неизвестным», — объясняю я, но знаю, что это не особо поможет. Мое объяснение того, ПОЧЕМУ команда хочет так много времени для выполнения такой небольшой работы, не делает их оценку меньше, и я это понимаю.

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

Для начала: Что такое оценка?

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

Данный вид оценок применим и для проектов по водопадной модели, но с нюансами.

Обычно это выглядит так:

Кто-то (обычно владелец продукта или продакт-менеджер или просто менеджер) представляет команде пользовательскую функцию, которую нужно разработать.
Команда и менеджер добавляют и корректируют пользовательские истории в бэклоге работ так, чтобы все необходимые задачи были представлены. Некоторые из них явно являются задачами разработки (написать тот или иной код), в то время как другие могут быть для кого-то смежного с командой (написать пользовательскую документацию, протестировать код разработчика и так далее).
Менеджер просит команду «оценить», сколько времени, по их мнению, займет выполнение работы и, следовательно, общее время, необходимое для вывода новой функции на рынок. Оценки могут быть в разных единицах измерения: от часов до «сторипойнтов» (это выдуманные числа в скраме, которые никто не понимает, но все притворяются, что понимают).
Теперь команда должна дать оценки того, сколько времени займет каждая задача, двигаясь сверху вниз, пока у нас не будет оценки для всей необходимой работы.

Почему это не работает

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

Причина №1: Страх

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

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

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

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

Как мы можем это исправить?

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

Причина №2: Нечеткие требования

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

Эти истории часто имеют плохо определенные или наполовину завершенные требования. «Добавьте кнопку, которая сохраняет данные в формате PDF». Хм, какие данные? Как должен выглядеть PDF? Должен ли пользователь иметь возможность скачать этот PDF? Нужно ли нам сохранять копию PDF? Вопросы продолжаются и продолжаются, и все они связаны с плохими требованиями.

Это очевидно. Действительно трудно оценить, сколько времени что-то займет, если мы точно не знаем, что нам нужно сделать, чтобы это было завершено.

Как мы можем это исправить?

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

Причина №3: Конформизм

Когда работаешь в команде, в ней могут быть оптимисты и пессимисты (они называют себя «реалистами»). Мой опыт показывает, что когда группу людей просят прийти к коллективному ответу, в целом эта группа будет склоняться к наиболее пессимистичному ответу.

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

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

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

Во-вторых, не позволяйте командам высказывать свое мнение в каком-либо порядке. Заставьте их использовать Planning poker (это как игральные карты, но с числом на них, которые все члены команды показывают одновременно, чтобы каждый давал свою честную оценку, а не просто соглашался с кем-то другим), или используйте пальцы, выброшенные в стиле «камень-ножницы-бумага», чтобы дать свою оценку.

В-третьих, позвольте людям спорить. Вообще-то, нет. ЗАСТАВЬТЕ людей спорить. Большинство программистов в командах обычно сидят тихо на таких сессиях, так что один или два человека в итоге доминируют в разговоре и оценках. Это нехорошо. Подталкивайте других членов команды к тому, чтобы они высказывались, аргументировали свои причины для более высокой или низкой оценки.

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

Причина №4: Мы все сделаем вчера! Или нет?

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

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

Как мы можем это исправить?

Нужно чтобы вся команда высказывалась, указывая, где оценки одного человека могут быть СЛИШКОМ амбициозными. Речь идет о том, чтобы отдельные члены команды высказывали свое мнение, объясняя вещи, которые один человек мог не учесть, поддерживая более стабильный баланс в оценке, обеспечивая учет всех точек зрения и возможностей.

Заключение

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

PMBOK 7: Руководство по выживанию в джунглях современных проектов

Wed, 02 Oct 2024 09:56:12 +0300

Недавно я закончил чтение PMBOK Guide 7-го издания, к этому чтиву я подходил 3 раза. Не самое легкое чтиво на вечер, но достаточно интересное. Это почти как фильм «Бойцовский клуб», при каждом прочтении открывается с новой стороны.

Шестую версию PMBOK не читал целиком, только ключевые тезисы, но довольно легко проследить тренды 7 версии. Ключевой вопрос для меня был как это применять на практике. Управление проектами — это динамичная область, где всё больше акцент делается на гибкость, адаптивность и ориентированность на ценность, и PMBOK 7 прекрасно отражает эти тенденции.

Кому стоит почитать.

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

Русская версия в формате pdf

История

PMBOK Guide 1-е издание (1996) — первое издание стандарта управления проектами.
PMBOK Guide 2-е издание (2000) — обновленное руководство с расширенной информацией по проектным процессам.
PMBOK Guide 3-е издание (2004) — акцент на связь между процессами и ключевыми областями знаний.
PMBOK Guide 4-е издание (2008) — добавлена четкость в описания процессов и методов управления проектами.
PMBOK Guide 5-е издание (2013) — добавлены процессы для управления стейкхолдерами.
PMBOK Guide 6-е издание (2017) — в этой версии было уделено внимание методологиям Agile, гибким подходам, и расширен раздел по управлению стейкхолдерами.
PMBOK Guide 7-е издание (2021) — значительно изменен, с акцентом на принципы и гибкость в управлении проектами. Меньше внимания уделено процессам, больше — адаптивным методологиям и результатам.

Изменение структуры и акцентов

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

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

Две ключевые части:

12 принципов управления проектами;
8 доменов производительности.

12 Принципов управления проектами

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

Быть ответственным управляющим
Создавать совместную команду проекта
Эффективно взаимодействовать с заинтересованными сторонами
Фокусироваться на ценности
Распознавать системные взаимодействия и реагировать на них
Демонстрировать лидерское поведение
Адаптироваться к контексту
Формировать качество в процессах и результатах
Ориентироваться на сложность
Оптимизировать реакцию на риски
Использовать адаптивность и устойчивость
Обеспечивать изменения для достижения желаемого будущего состояния

8 Доменов производительности

Эти домены заменяют процессные группы, знакомые по предыдущим версиям. Теперь акцент делается на результатах и областях, которые требуют внимания в каждом проекте:

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

Модели, методы и артефакты

PMBOK 7 вводит концепцию моделей, методов и артефактов (MMA) вместо жестко определенных процессов. Это позволяет менеджерам проектов выбирать наиболее подходящие инструменты для конкретного проекта.

Модели: Включают Agile, гибридные подходы, предиктивные модели.
Методы: Охватывают различные техники, такие как ретроспективы, планирование релизов, оценка стоимости.
Артефакты: Включают документы и инструменты, такие как устав проекта, журнал проблем, диаграмма Ганта.

Области эффективности

PMBOK 7 вводит восемь областей эффективности проекта:

Заинтересованные стороны
Команда
Подход к разработке и жизненный цикл
Планирование
Работа проекта
Доставка
Измерение
Неопределенность

Эти области заменяют 10 областей знаний из предыдущих версий, обеспечивая более целостный взгляд на управление проектами.

Гибкость и гибридные подходы

В 7-м издании значительно усилился акцент на гибкость и гибридные модели управления проектами. Это стало реакцией на популярность Agile и других гибких методологий, которые требуют более адаптивного подхода к планированию, выполнению и завершению проектов. Основная идея — менеджеру проекта нужно быть готовым адаптировать методологию и подход под конкретный контекст и задачи, будь то классический Waterfall, Agile или их гибрид.

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

Уровне неопределенности проекта;
Скорости изменений;
Требованиях заказчика и стейкхолдеров;
Характеристиках команды.

Технологический и человеческий факторы

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

Tailoring (настройка процесса управления под проект)

Одной из самых важных практических тем стало понятие tailoring, что означает настройку и адаптацию методологии под конкретный проект. В предыдущих версиях PMBOK предполагалось жесткое следование процессам, тогда как в 7-м издании менеджер проектов должен адаптировать подходы к уникальности проекта, в том числе:

Объем проекта;
Риски и неопределенности;
Внешние и внутренние условия;
Компетенции команды.

Интеграция с другими стандартами и фреймворками

7-е издание PMBOK не является изолированным стандартом, оно интегрируется с другими фреймворками и стандартами, такими как Agile Practice Guide, Scrum, SAFe и другими гибкими методологиями. Это позволяет менеджерам проектов выбирать подходящие инструменты и методы из разных стандартов в зависимости от требований проекта.

Итого

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

Используйте 12 принципов как руководство при принятии решений в проекте.
Адаптируйте подход к управлению проекту в зависимости от контекста и потребностей.
Выбирайте модели, методы и артефакты, наиболее подходящие для вашего проекта.
Фокусируйтесь на создании ценности и достижении результатов, а не только на процессах.
Регулярно оценивайте эффективность проекта в восьми областях эффективности.
Будьте готовы к гибкому подходу и адаптации к изменениям.

Парадоксы управления

Tue, 24 Sep 2024 18:40:06 +0300

Вопрос: как управленец, вы должны быть:
Уверенным или скромным? Стратегом или тактиком? Энергичным или спокойным?

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

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

Уверенность vs Скромность

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

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

Вывод: Уверенность необходима для поддержания морального духа и направления к целям. Однако скромность и искренность важны для решения сложных проблем на пути к этим целям.

Стратегия vs Тактика

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

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

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

Решительность vs Гибкость

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

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

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

Вывод: Решительность важна для прогресса и во избежание застоя или движения по кругу. В то же время гибкость важна для обеспечения адаптации к окружающей среде для оптимизации выполнения.

Стойкость vs Уязвимость

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

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

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

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

Эмпатия vs Жесткость

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

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

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

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

Делегирование vs Контроль

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

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

Однако ваша кампания должна быть запущена через 4 недели, и вы устанавливаете четкие сроки — включая внутренние проверки — которые ваша команда должна соблюдать и регулярно предоставлять обновления о прогрессе.

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

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

Энергичность vs Спокойствие

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

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

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

Сдержанность vs Прозрачность

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

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

Но у вас также есть доступ к конфиденциальной информации — юридической, финансовой — которую нужно хранить в строгом секрете. Это защищает интересы компании и поддерживает вашу репутацию.

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

Личное vs Профессиональное

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

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

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

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

Итог

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

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

Чем лучше вы способны распознавать их, тем лучше вы сможете с ними справляться.

Agile-проекты превратились в проекты Waterfall со спринтами

Wed, 11 Sep 2024 16:36:17 +0300

Из гибких проектов высосана вся гибкость

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

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

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

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

Agile обещал ускорить разработку ПО и обеспечить клиента более быстрый возврат инвестиций за счет быстрой скорости разработки и вывода проект. Однако реальность часто не соответствует этим ожиданиям, и в 99% случаев результаты agile-проектов разочаровывают.

Агайл превращается в скуфа

Agile стал настолько популярным, что клиенты или выбирают компании / команды которые работаю с ним или начали требовать agile подход у проекта, даже если этот подход не подходил для их задач или у них не было нужных специалистов.

В книге «Sooner Safer Happier» авторы критикуют тенденцию использовать Agile формально, вместо того чтобы действительно быть гибкими. Agile превратился в продукт, а не образ мышления.

Многие компании и команды разработчиков стремятся к «agile-поставке», которая включает бэклоги продукта, спринты и фиксированные сроки/стоимость. При этом ключевые элементы гибкости часто игнорируются:

Ретроспективы исчезли
Гибкость и изменение методов работы ушли в прошлое
Быстрая поставка в производство стала редкостью
Ожидается строгое соблюдение сроков
Команды лишены реальных полномочий и автономии

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

Само слово «Agile» потеряло свое значение, а из Agile-проектов выжали всю реальную гибкость.

Худший из миров

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

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

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

Wagile

«Гибридный» подход, сочетающий элементы Agile и каскадной модели (иногда называемый «wagile»), не подходит для создания уникального программного обеспечения. Это попытка совместить несовместимое, которая приводит к созданию нереалистичных планов, задержкам и увеличению затрат.

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

Зачем мы сюда попали?

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

Теперь мы наблюдаем эффект «трава зеленее»:

Раньше, на фоне проблем Водопада, Agile казался идеальным решением
Теперь, столкнувшись с проблемами Agile, некоторые ностальгируют по более структурированным подходам

Слишком заняты, чтобы думать

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

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

Методология Agile не исчезнет, но она находится в стадии «дойной коровы» — проекты используют термин Agile, не являясь по-настоящему гибкими.

Заключение

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

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

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

Ключевые факторы успеха проекта остаются неизменными:

Четкое понимание целей проекта
Эффективная коммуникация между всеми участниками
Компетентная и мотивированная команда
Реалистичные ожидания и планирование
Гибкость в адаптации к изменениям
Фокус на создании ценности для пользователей

Вместо слепого следования какой-либо методологии, командам стоит:

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

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

В конечном счете, ключ к успеху — это люди: их навыки, мотивация, способность к сотрудничеству и решению проблем. Никакая методология не заменит талантливых и увлеченных профессионалов, работающих вместе над достижением общей цели. Там что всех нас ждет Wagile, недо Scrum и прочие методологии.

Бюрократ, самодур, циник и наседка

Thu, 05 Sep 2024 14:46:18 +0300

Интересная свойства для руководителя, не правда ли?

Не так давно я вернулся с конференции для агентств и продакшенов, где темы были довольно интересными, а спикеры поделились ценным контентом и своими инсайтами. Среди всех выступлений особенно запомнился доклад Алексея Кельина на тему «Выращиваем управленческий состав. Модель органичного лидерства».

Эта тема откликнулась в моем сердце, вероятно, потому что она лично для меня довольно интересная, болезненная, и именно этим я сейчас активно пытаюсь заниматься в своей работе. Сам доклад был довольно коротким для столь обширной темы, но, как оказалось, существует версия лекции продолжительностью 2,5 часа, доступная на YouTube.

Я не мог упустить возможность углубиться в эту тему и посмотрел полную версию.
Лекция Алексея раскрывает множество аспектов лидерства и управления, от базовых стратегий до высших уровней развития руководителя. Она заставляет задуматься о собственном стиле управления, его сильных сторонах и возможных «подводных камнях». Более того, она предлагает пути развития для лидеров, стремящихся выйти на новый уровень управления.

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

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

Базовые стратегии управления

Командир: Использует личную власть и авторитет для достижения целей. Командир добивается исполнения через прямые указания и контроль.
Опекун: Объединяет людей и налаживает связи между ними. Опекун фокусируется на создании гармоничной рабочей атмосферы и поддержке сотрудников.
Координатор: Обеспечивает взаимодействие между сотрудниками и является связующим звеном. Координатор организует работу команды и следит за выполнением задач.
Регулятор: Достигает исполнения через внедрение и поддержание правил и нормативов. Регулятор создает систему правил и процедур для эффективной работы.

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

«Темная сторона» базовых стратегий

Каждая стратегия может иметь свою «темную сторону»:

Регулятор может стать бюрократом-формалистом, чрезмерно фокусируясь на правилах в ущерб эффективности.
Командир может превратиться в тирана-руководителя, ценящего личную преданность выше эффективности.
Опекун рискует стать чрезмерно заботливой «нянькой», не давая сотрудникам возможности развиваться самостоятельно.
Координатор может стать «подрезателем», постоянно меняющим планы и цели без объяснения причин.

Условия перехода на «темную сторону» включают выгорание, потерю мотивации, несоответствие команды стилю управления и отсутствие интересных целей.

Объединяющие лидерские стратегии

По мере роста организации руководитель начинает выстраивать системы для управления:

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

Развитие лидера и следующий уровень

Для перехода на новый уровень лидеры должны освоить смежные стратегии и преодолеть определенные внутренние барьеры:

Вождь (развитие командира)

Должен освоить навыки регулятора и опекуна.
Создает систему порядка, безопасности выполнения плана и лояльности.
Выстраивает иерархию, распределение власти и идентичность «племени».

Синергет (развитие опекуна):

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

Визионер (развитие координатора):

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

Франшизер (развитие регулятора в бизнес-технолога):

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

Цена развития и «ночные кошмары» лидеров

Переход на следующий уровень требует внутренней трансформации и готовности платить определенную цену:

Командиры должны отказаться от своего эго и научиться сдерживаться. Их «ночной кошмар» — делегирование власти.
Опекуны должны перестать быть связующим звеном команды. Их страх — потеря любви и уважения сотрудников.
Координаторы должны научиться делегировать контроль. Их опасение — потеря контроля над происходящим.
Регуляторы боятся анархии и отсутствия правил, поэтому должны научиться доверять установлению правил на нижестоящих уровнях.

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

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

Ссылочка на видео, спешите пока еще работает: https://www.youtube.com/watch?v=PbxZaaXTGn4

TG Алексея — https://t.me/AlexeyKelyin

Удаленка умирает? Не спешите с выводами!

Tue, 03 Sep 2024 09:05:41 +0300

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

Крупные предприниматели, вроде Джеймса Дайсона, уже заявляют, что удаленка — это «ошеломляюще саморазрушительный» подход, который не стоит воспринимать как право сотрудника. Мол, это не тот инструмент, который должен давать человеку свободу, а скорее ловушка, разрушающая мотивацию.

Эрик Юань основатель Zoom, неоднократно говорил о преимуществах удаленной работы, особенно в контексте пандемии COVID-19. Он признает, что гибридная модель (сочетание удаленной и офисной работы) будет нормой для многих компаний в будущем. Однако он также отметил, что, несмотря на популярность удаленной работы, для многих сотрудников важно возвращение в офис для сохранения корпоративной культуры и продуктивного взаимодействия.

Джейми Даймон (CEO JPMorgan Chase) выразил свое негативное отношение к долгосрочной удаленной работе, особенно для младших сотрудников. Он считает, что удаленная работа не подходит для обучения новых сотрудников и для креативных процессов. Даймон также подчеркнул важность личного присутствия для корпоративной культуры и формирования командного духа.

Илон Маск (CEO Tesla и SpaceX) был одним из самых известных противников удаленной работы. Он заявил, что все сотрудники Tesla и SpaceX должны вернуться в офисы на полный рабочий день, если они хотят продолжать работать в компании. Маск считает, что личное присутствие необходимо для достижения высоких стандартов производительности и инноваций, особенно в таких компаниях, как Tesla, где нужно создавать и тестировать физические продукты.

Диагноз по аватарке

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

Эпоха пандемии ушла

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

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

Удаленка не работает для 90% людей

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

Эра фриланса и удаленной работы уходит

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

Плохой баланс между работой и личной жизнью

Работай где хочешь и когда хочешь! Разве это не прекрасно?

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

Удаленка не умрет, не сейчас

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

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

Микроменеджмент: недооцененное искусство управления в IT

Mon, 26 Aug 2024 18:16:17 +0300

Хочу поднять тему, которая вызывает бурные споры в нашей индустрии — микроменеджмент. Да-да, тот самый подход, от которого многие разработчики бегут как от чумы. Но давайте копнем глубже и посмотрим, может ли этот «монстр» быть полезным в мире IT.

Микро vs Макро: в чем суть?

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

Макроменеджмент — это когда вам дают задачу, дедлайн и говорят: «Вперед, ты же профессионал, разберешься».
На первый взгляд, макро подход кажется идеальным. Но не спешите с выводами!

Неожиданные плюсы микроменеджмента в IT:

1. Внимание к деталям

В проектах, связанных с финансами, медициной или безопасностью, одна маленькая ошибка может стоить миллионы или даже жизни. Здесь микроменеджер — не зло, а необходимость. Представьте, что вы разрабатываете софт для управления атомной электростанцией. Лишняя проверка тут точно не помешает.

2. Быстрый рост джунов

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

3. Высокая ответственность

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

4. Быстрое решение проблем

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

5. Эффективное использование ресурсов

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

6. Улучшенная коммуникация

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

7. Поддержание стандартов кода

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

Но не все так радужно...

Риски микроменеджмента в IT:

1. Выгорание разработчиков

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

2. Выгорание самого менеджера

Следить за каждым шагом команды — та еще работенка. Менеджер рискует погрязнуть в деталях и упустить стратегические цели.

3. Подавление креативности

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

4. Замедление процессов

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

5. Потеря доверия

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

Золотая середина: как применять микроменеджмент в IT?

1. Используйте микроменеджмент для критически важных задач.

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

2. Применяйте к новичкам, но с умом.

Помогайте джунам расти, но постепенно давайте им больше свободы.

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

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

4. Будьте гибкими.

Адаптируйте уровень контроля под конкретного сотрудника и ситуацию.

5. Объясняйте свои действия.

Если вы как менеджер решили усилить контроль, объясните команде причины. Прозрачность — ключ к пониманию.

6. Фокусируйтесь на результате, а не на процессе.

Да, вы контролируете детали, но главное — достижение цели.

7. Регулярно получайте обратную связь.

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

Итог

Микроменеджмент в IT — это как мощный инструмент в руках опытного мастера. Использованный правильно, он может значительно повысить качество продукта и ускорить рост команды. Но применять его нужно с умом, чутко реагируя на потребности проекта и команды.

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

P.S. Этот пост я писал под чутким руководством своего внутреннего микроменеджера. Надеюсь, он не слишком меня замучил! 😉