К черту кварталы – работаем от праздника до праздника
Около года назад мы в команде всерьез задумались о пересмотре сроков среднесрочного планирования. И всему виной наш любимый производственный календарь РФ. Но начнем издалека.
Традиционно мы привыкли встречаться раз в три месяца, квартал, ставить цели, возвращаться через квартал подводить итоги, ставить новые цели и так до бесконечности (хочется верить).
Но 2022 год стал для нашей компании поворотным периодом. Мы занимаемся разработкой онлайн-доски для совместной работы, где можно проводить стратегические сессии, ретро, брейнштормы, построение воронок продаж и т.д. И лишившись значимой доли иностранных конкурентов, нам представилась отличная возможность занять большую нишу рынка.
Чтобы достичь этой цели, мы решили сделать необычное (конечно, нет) – сделать ставку на масштабирование команды, улучшение процессов планирования и разработки. Самое главное: выпустить версию 2.0. Это должна была быть написанная с нуля новая онлайн-доска, которая возьмёт всё самое лучшее от предыдущих двух лет существования продукта (версии 1.0), но для новой целевой аудитории - бизнеса. В том числе с возможностью поставки в контур заказчика. Спойлер: мы это сделали, посмотреть можно здесь - ссылка.
При этом надо было помнить, что компания является стартапом и не может позволить себе раздуть ФОТ, погрязнуть в кризисе роста и потерять общую эффективность, которая складывается из результатов каждого члена команды.
Глядя на все это, мы решили попробовать спланировать следующий год. И тут у нас случилось интересное озарение.
Все предыдущие года, мы ставили себе цели на периоды по три месяца: с января по март, с апреля по июнь, с июля по... Ну вы поняли. И нас все устраивало, но был важный нюанс. Все это время мы работали супер небольшой командой, часть из которой была представлена аутстафом и жила вообще не по трудовому календарю РФ. Что уж говорить про фаундеров, которые всеми силами выбирались из долины смерти, иногда забывая про сон.
Мы начали собирать команду из РФ, нас стало кратно больше. Да и стало пора самим задумываться про тот самый work-life-balance, ходить в отпуска и закрывать ноутбук в красные дни календаря.
И вот здесь нас сильно смущало, что на середину второго квартала приходятся майские праздники, когда многие уезжают сажать картошку в Турцию. Третий квартал приходится на август-начало сентября - идем в отпуск, отправляем детей в школу, в целом начинаем новый сезон деловой активности и все это в середине нашего периода планирования.
А вот четвертый квартал оказался единственным приятным – все знают, что после него будут новогодние каникулы и можно по-максимуму выложиться и с чистой совестью уйти в загул.
Мы хотели, чтобы у нас каждый квартал был как четвертый.
Вопрос - возможно ли это?
Мы решили развить эту мысль. Но как бы вы не двигали начало первого квартала, так или иначе где-то посреди вашего периода планирования будут праздники – это Россия.
В общем думали-думали и внезапно придумали – а что если планировать не на 3 месяца, а на 4?
То есть мы начнем в Январе, выложимся к Маю, уйдем на майские. Дальше продолжим в Мае, к августу сходим все в летние отпуска и со свежими силами ворвемся в сезон высокой деловой активности – сентябрь. Дальше все как мы любим – будем давить на газ до декабря, чтобы 1-го января открыть шампанское и отметить удачное завершение года.
Эта идея настолько нас зацепила, что мы решили, что не сможем пройти мимо и не попробовать.
Прошел год...
Сейчас мы хотим предостеречь всех. Не делайте так. Только если вы не хотите, чтобы ваша команда работала со зверской результативностью, люди были заряжены 80-100% периода планирования, не выгорали, вовремя отдыхали и при это не снижало общую координацию в команде.
Серьезно. Мы теперь не понимаем, как можно было раньше жить по-другому. На майские вообще теперь думает сделать традицию собираться всей командой, подводить итоги, отрываться вместе, а потом возвращаться, выкладываться и уходить в августе в отпуска – там все равно вся страна на море. Остальную часть отпусков можно всегда привязать к окончанию либо началу других периодов.
Мы кстати долго думали, как можно назвать такой период, и не нашли ничего лучше, как называть их сезонами – Осенний, Зимний и Летний. Если у вас есть идея, как можно назвать иначе, напишите, пожалуйста, в комментарии.
Подводя итог, хочется сказать, что очевидно эксперимент стал возможен потому что мы пока небольшая команда и можем себе позволить быстрые проверки. Более того, мы бы не выжили и не достигли бы текущих результатов без постоянных гипотез и экспериментов. И конечно же планирование от праздников до праздников – это не единственное, что поддерживает нашу мотивацию и командный дух. Но, кажется, что из таких мелочей и складывается в конечном счете большой результат.
Отдельно хочется отметить, что бухгалтерская отчетность в нашей компании – это параллельный процесс, и мы можем себе позволить не привязываться к фискальным периодам. Интересно было бы узнать ваше мнение, если у вас иначе.
Надеемся, что было интересно прочитать о нашем опыте, мы будем рады любой обратной связи в комментариях.
100% органический материал, без добавления chatGPT
Когда менеджер считает, что сложные решения можно принять на основе гороскопов и карт таро
Всех с новой трудовой неделей!
Менеджер: посмотри, насколько эффективна моя команда, график идет вверх
Разработчик: сэр, это график сгорания работы
Bus factor
Зарплатные вилки, вредные советы и блокировка Slack: проектный дайджест за неделю
Что интересного писали про управление проектами за прошедшую неделю.
Встречайте очередной обзор публикаций VC и Хабра о проектах и проектном управлении. Раньше я публиковал его на vc, но если на Пикабу зайдет, перееду сюда.
Основы теории и гайды
Гайд по написанию пользовательских историй и критериев приёмки
Аналитик из крупной компании делится своим большим опытом написания user story. Много картинок, схем и лайфхаков.Теория ограничений Голдратта и проектное управление. Что за диагональный буфер?
Ммм, материал явно не для начинающих, но интересный. Теория ограничений - отдельный феномен, с одной стороны, простой, с другой - более чем заморочный, и автору статьи плюс за попытку объяснить.Продукт VS проект: отличия подходов
Автор идет от интуитивно понятных отличий к более глубоким методологическим различиям между продуктовым и проектным подходом (попутно там рекламирует свой продукт, но это таки не мешает пониманию).PM GUIDE: зачем нужен еще один стандарт управления проектами?
Честно скажу, что вот тут реклама чуть более, чем полностью, - но вдруг кому-то курс этого автора поможет с поиском профессии или методологии.
Проект-менеджер и команда проекта
Исследование: в 2022 году зарплатная вилка у большинства продуктовых специалистов составила 180-220 тысяч рублей
Там и проект-менеджеров есть, и выводы не в нашу пользу, коллеги: "вилка" на 30-50% ниже, чем у продактов. Также в статье есть про самые распространенные форматы работы, про трудности и обязанности.«Растишка» не поможет: 6 ошибок, из-за которых менеджеры-джуны остаются джунами
Очень неплохой разбор типичных ошибок, которые допускают проект-менеджеры на старте (и не только) своей карьеры, и рекомендации, как их не допускать.6 важных скиллов, которыми должен обладать хороший PM
Снова "шесть", - короткий материал, скорее шпаргалка или экспресс-мнение, про умения и навыки проджекта.Найм, адаптация и развитие проджект-менеджера: опыт Nimax. Часть 1
Собственно, сабж, очень подробный, с примерами, рассказ о процедуре поиска и найма проджектов в компанию.Что общего между галерой (ладно, яхтой) и ИТ-командой
Отличная, хорошо написанная статья про то, как руководить, создавать, направлять и при этом оставаться человеком.Что делать, если ваш руководитель чайка-менеджер
Взгляд с другой стороны, не совсем про проекты, но рядом. Что такое "чайка-менеджмент", все знают, - и публикация приводит примеры и способы реагирования.Как делать проект восемь месяцев вместо двух. Вредные советы для менеджеров
Свежая порция вредных советов (топовый жанр, кстати). В этот раз - про важность ролей, вовлечение и бэклог.Клиент & Команда разработки: как бизнес может влиять на результат
Рекомендую - полезный материал о том, как бизнес давит на команду проекта и на ходу иногда перепридумывает проект, а команда... ну, как-то реагирует, выживает и создает продукт.Бизнес-аналитик внутренних технологий
Две публикации, детально рассказывающие о важных ролях проектной команды.
Личный опыт и дискуссии
Как не надо объяснять людям задачи и изменения
Очень развернутый рассказ с массой примеров про неэффективные и эффективные способы постановки задач. Коротко - нужно объяснить исполнителю цель, описать конечный результат и расставить контрольные точки, собирать обратную связь с потребителей и документировать процессы.Как описать идею проекта для технической команды?
Авторы делятся своей методикой - вместо ТЗ от заказчика они берут короткое описание его хотелок на его же (заказчика) языке, утверждают, а уже внутри команды переводят всё в требования, понятные программистам.Как соблюдать сроки. Интересная теория: 4 типа восприятия времени
Вы продавили подрядчика, последствия
Незаслуженно обойденная вниманием публики статья про то, как торговаться за проект, как не продешевить и чем чревато радикальное снижение бюджета. С примерами из жизни.Внедрять или не внедрять: как обосновать необходимость системы управления проектами
Своеобразный переход к следующей теме про инструменты. Статья про то, как наиболее эффективно подступиться к руководству с просьбами купить (и еще и потратиться на внедрение) софт для ведения проекта.
Инструментарий
Как обычно, тут без аннотаций, большинство статей имеет говорящие названия.
Slack окончательно блокирует пространства Российских компаний. Все подробности о происходящем
16 ресурсов (бесплатных и платных), которые прокачали мой Notion
Правила работы в Power Point, которые сэкономят время и улучшат презентации
Microsoft сделала бесплатным доступ к Loop — похожему на Notion сервису для совместной работы
Общаться прозрачнее и работать быстрее: применяем методики Agile в Yandex Tracker
Опередить события: Использование инструментов управления проектами "Битрикс24" для достижения успеха
Видео
Вот такой была неделя публикаций о проектах на vc.ru и Хабре. Если мы пропустили какой-то ценный материал — поделитесь им в комментариях. Предложения по формату и содержанию — приветствуются!
Да, и если вы автор публикаций по теме проектов — маякните в комментариях, чтобы мы вас не потеряли!
Поиграем в бизнесменов?
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Agile мёртв
Автор: Алексей Александрович Самойлов
Agile продолжает шагать по стране, захватывая умы всё новых адептов и поддерживая своё влияние в головах старых. Различные компании и команды пробуют «внедрять Agile» (подход к управлению проектами) в меру своего понимания и с разной степенью успеха.
Пока в России продолжают активно издавать книги, проводить конференции, продавать обучающие курсы, сертификаты — многие и не знают, что ещё 8 лет назад один из основателей и популяризаторов этого движения заявил, что Agile мёртв.
Но кто же следит за информацией по своей теме, тем более если она только на английском языке?
Специально для уважаемых Читателей канала VIKENT.RU мы разберем основные претензии Дэйва Томаса, одного из Авторов Agile-манифеста, к тому, что сейчас из себя представляет Agile.
Исходная проблема, которая возникла в конце 90-х годов — 99% проектов разработки ПО выглядело, как борьба на баррикадах в формате «сделай или умри». Хотя это было весело, но большая часть проектов умирала.
Разработка ПО была нестабильна, и возникло очень много людей, недовольных этой ситуацией, хотя нельзя сказать, что это было единое движение. Тут и там возникало много различных инициатив, которые пытались решить накопившиеся проблемы — экстремальное программирование, адаптивная разработка ПО, концепция программиста-прагматика, методологии семейства Crystal. Scrum тоже был где-то рядом ещё с 80-х.
Поворотным событием стала встреча в снежной Юте, где несколько представителей профессии собрались обсудить сложившуюся плачевную ситуацию в мире разработки ПО. Тогда и был написан Agile-манифест.
Спустя 15 лет Дэйв Томас — один из Авторов манифеста, накопил ряд претензий к тому, во что последователи превратили исходную идею. Претензий всего 5, и давайте их разберём.
1. Существительное вместо прилагательного
Эта ошибка заявлена, как исходная, которая в дальнейшем привела к искажению понимания принципов Agile, ведь точное название манифеста «Манифест гибкой разработки программного обеспечения», а люди стали сокращать его до «Agile манифест» (гибкий манифест — прим. Алексея Александровича Самойлова)., а надо было называть хотя бы «Манифест гибкости». Agile (гибкий) — это прилагательное и все, кто употребляет его, как существительное («я занимаюсь agile») делает ошибку. Например, нельзя при продаже сказать «купите у меня немного зелёного», это не работает. Можно сказать «зелёный рисунок» или «зелёные овощи». Можно продать существительное, но нельзя продавать прилагательное.
Хотя индустрия, возникшая вокруг этого манифеста, стремится продать вам — тренинги, консалтинг, книги и конференции и у них получается сформировать запрос именно в формате «взвесьте мне килограмм agile (гибкости), пожалуйста».
Но всё даже хуже.
Самое важное для бизнеса — это продажи. И индустрия, которая выросла вокруг этого, работает на страхе.
Появилось много новых слов — скрам, канбан, спайк — которые люди раньше не слышали, поэтому нервничают, не понимая, как их использовать. И теперь нужен переводчик, который придёт к вам на целый день и выставит счёт, чтобы рассказать, что такое спайк.
Сейчас концепция использования Agile, как существительного, стала индустрией. Это машина, работающая на нашем страхе, и просящая нас платить деньги, чтобы успокоить этот страх.
Также появились новые правила в иерархии проекта, и люди боятся, что прежняя структура, которая позволяла управлять организацией сломается, а новая не заработает.
И главное, когда мы начинаем делать что-то новое, появляются сомнения, что мы делаем это правильно.
Успешные люди думают, что у них есть право говорить другим, что и как надо делать.
Если получается добиться успеха в каком-то деле, то возникает иллюзия, что ты что-то знаешь такое, чего не знают остальные. А все, кто видят этот успех, хотят также попробовать этим заняться и повторить. Всегда можно забрендировать этот новый подход. И это подталкивает усложнить жизнь для остальных людей, причём не со зла, а просто так получается само собой.
Например, Ruby-программисты очень сильно продвинулись в деле тестирования, чем кто-то другой в истории вычислений. У них развитая культура тестирования и проводится много экспериментов, разработано много методов тестирования, которые были перенесены потом в другие языки программирования. Но когда кто-нибудь не покрывает всё тестами на 100%, они смотрят на тебя презрительно и говорят: «А я думал, ты программист... Тогда не интересно, чем ты занимаешься, вали отсюда.»
Есть американская поговорка «не позволяй индюкам сломить тебя». Эти люди индюки. Не позволяйте им говорить Вам, что надо делать. Я тоже индюк.
С Agile происходит тоже самое — то, как мы делаем это и есть эталон, если ты делаешь по-другому, то ты второй сорт.
Agile подход создан для маленьких команд и проводятся конференции, чтобы можно было масштабировать лучшие решения. Но открытие заключается в том, что в маленьких командах не очень много денег, поэтому они не интересны для продаж. Деньги находятся в больших компаниях, и надо было найти возможность адаптировать подход на них. Поэтому стали разрабатывать новые варианты, противоречащие изначальным принципам. И Agile, который разработан для маленьких команд, теперь используется для больших корпораций.
Иначе на Agile не заработаешь.
Нет универсальных правил (кроме этого).
Для каждого правила нужен контекст. Например, правило «нельзя тыкать ножом в другого человека» хорошее до тех пор пока это не хирург, которому надо делать операцию. На просьбу прислать хотя бы одно универсальное правило пока никто не откликнулся.
Все правила завязаны на контексте. Любая книга «Как разрабатывать ПО» неправильная, т.к. написана не для вашей команды, компании, проекта, поэтому Авторы не знают точно, как конкретно Вам надо разрабатывать ПО.
Поэтому в Agile не может быть стандартов, подходящих всем.
Дэйв Томас считает, что выход из тупика может быть при использовании в проектах следующего цикла:
1. Определиться, где Вы находитесь.
2. Сделать маленький шаг к Вашей цели.
3. Оценить, что получилось.
4. Вернуться на Шаг-1.
Пытливые умы могут сравнить его с циклом Шухарта-Деминга. А всем остальным рекомендуется ознакомиться в доп. материалах с ошибками изучения творчества, где разбирается метод проб и ошибок.
Но нам с Вами будут больше интересны выводы о совершённых ошибках в истории Agile.
Решения сложных проблем не создаются путём обсуждений и выдумыванием решений из головы.
Простыми декларациями, призывами, манифестами стать лучше, делать всё хорошо и т.п. не решить сложных проблем, которые копятся десятилетиями. Но можно запутать других и кто-то сможет заработать на этом.
Коллективы Разработчиков нового и условия, в которых они работают, слишком разные, чтобы для всех можно было сформулировать общие рекомендации, без учёта контекста.
Всем Разработчикам и Исследователям рекомендуется учиться на чужих примерах и не повторять этих ошибок.
Большинство проектов так и остаются неудачными, т.к. методология их разработки до сих пор не создана. Это касается не только сферы IT, но и большинства других. И чем сложнее проект, тем выше вероятность неудачи.
Автору статьи неизвестно, где КАЧЕСТВЕННО учат (даже за деньги) созданию своих проектов, методик и иных разработок, кроме проекта VIKENT.RU. Если уважаемым Читателям известны такие примеры, то просьба привести их в комментариях.
А для более глубокого погружения в тему рекомендуется проработать дополнительные материалы:
Доп. материалы по теме1) (видео 8 мин.) #тестирование НОВЫХ ТВОРЧЕСКИХ ПРОДУКТОВ / РАЗРАБОТОК
2) (видео 12 мин.) Почему новые методики креатива будут похожи на ТРИЗ?
3) (видео 87 мин.) #консультация № 255 о создании авторских методик по принятию решений
4) (видео 46 мин.) ПРИНЯТИЕ ТВОРЧЕСКИХ РЕШЕНИЙ: ЭТАПЫ / СТАДИИ (ВИДЕОСЛОВАРЬ VIKENT.RU)
5) (видеозадача 3 мин.) Как исказили Waterfall?
Источники материалов
Agile is Dead • Pragmatic Dave Thomas • GOTO 2015 https://www.youtube.com/watch?v=a-BOSpxYJ9M
AGILE IS DEAD (LONG LIVE AGILITY) https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
Agile-манифест разработки программного обеспечения https://agilemanifesto.org/iso/ru/manifesto.html
CHAOS Reports www.standishgroup.com
Благодарности вычитывающим:Благодарю А. А. Морозова, А. И. Трушинского и И. Л. Викентьева за вычитку и рекомендации по усилению данной статьи. Отдельно А. А. Морозову за иллюстрации.