Олдскулы
Как аккредитованный тренер PSM II я обещаю с радостью с вами подискутировать :)
Мои выводы основаны на том факте, что в конце статьи вы так и не подвели итоги, а "что же пошло не так" и чтобы вы сделали с процессами иначе при своей следующей попытке "диджитал трансформации" конструкторского агентства.
Вместо этого вы как "аккредитованный тренер" предлагаете людям купить ваш продукт и натянуть Канбан на табуретку - не надо так. Это не решит их системные проблемы.
Я в итоге так и не понял, по какому "процессу" в конце концов была организована работы команды, и не смог оценить он устойчив к изменениям в перспективе, хотя в этом и есть стресс любого вручную настроенного потока работы.
...
К сожалению, ваш подход к изменениям рушит индустрию и только прививает ненависть к всем видам Technical/Product Management.
У вас ничего не получилось, потому ваши свистелки не решали корень проблемы и не меняли сам процесс управления продуктом внутри компании.
Надеюсь, что в следующий раз, вы всё-таки сможете грамотно коммуницировать со "старичкам" и прислушиваться к их мнению, чтобы понять действительные проблемы в системы и научиться изменять её снизу вверх.
Дизайн Канбана - это оптимизация ПОТОКА внутри процесса. А не сам процесс /методология управления проектами.
Вы технически не можете уничтожить процесс и заменить его рядом потоков. Даже если в вашей голове картина мира сложилась таким образом - процесс на самом деле никуда не исчез.
«Мы работаем по Канбану». Это тоже некорректно - Канбан используется для обёртки существующего процесса, его можно применить к Scrum, XP, DSDM, Водопаду, и это будет полезно. Но судя по вашей иллюстрации, Chaos Engineering, приукрашенный Канбаном, из вашей системы никуда не делся. От сюда и корень проблем.
Канбан применяют к уже существующему процессу, а не как что-то отдельное.
Эволюция процесса основана на понимании Business Value ваших продуктов, клиентов, культуры внутри компании, ментальных заскоков владельцев и инвесторов. Без глубокого анализа этих составляющих вы не можете построить эффективный процесс улучшающих важнейшие бизнес метрики.
Вот это вот уровни программистов не курильщика в 2023 году, а не ваш скриншот снизу
https://www.levels.fyi/?compare=Google,Facebook,Microsoft&track=Software%20Engineer#
Значит папа пытается демпить рынок продавая услуги дешевле, чем они стоят на самом деле.
От сюда все в проигрыше:
- неадекватные ожидания заказчиков на "простенькую нейросеть с бесплатным саппортом на два года"
- меньше колбасы для сына
- меньше опций у крузака для папы
- заказчик расстроен качеством своего ай котейко-генератора за 100К, и не может масштабировать это что-то даже чтобы окупить вложения, от чего ещё сильнее снижаются ожидания на стоимость разработки.
Всё-таки, признайте, что большие компании имеют гораздо более актуальную и состоянии и потребностях рынка в силу масштаба их проектов.
А вам стоит принять позицию, что базовая з.п. специалиста в "маленьком агентстве" должна быть больше, чем в Яндексе.
Не забывайте, что Яндекс и другие публичные компании ещё и акций отсыпают на 100-200% от базовой ставки.
У вас таких возможностей нет, поэтому надо как-то компенсировать.
Да, софт - это дорого. И инвестировать стоит туда, где можно приумножить затраты успешно масштабируя сервис.
Иначе, вам это не нужно.
2023? Что-то вы как-то отстаёте от индустрии лет 15..
Давно уже принята Senior+ градация для удержания старшего персонала.
Senior -> Staff -> Sr Staff -> Principal -> о боже Distinguished Engineer для тех кто не хочет переходить в управление и оставаться Individual Contributor по карьерной лестнице.
Чувак на скриншоте в чём-то всё таки прав. После 10 лет работы инженеры всё-таки становятся Language/Framework-агностик.
База это всё, но у них не очень принято спрашивать детали имплементации в конкретном случае.
Любой новый язык и фреймворк учится по одноименной книжке за 2 недели.
Если ещё не ознакомились, я рекомендую начать с классики:
- Ицхак Адизес: Как преодолеть кризисы менеджмента.
- Эффективный руководитель, Питер Друкер.
- Мифический человеко-месяц, Фредерик Брукс.
- Agile ретроспектива. Эстер Дерби.
Далее, можно углубится во фреймворки планирования и принятия решений, наиболее подходящие вашей структуре:
- Foundation of Decision Analysis, Ronald A. Howard
- An Elegant Puzzle, Will Larson - если вы ближе к инженерии
Спасибо за статью, очень интересная ситуация и способы её решения, и правда заставила задуматься о текущем менталитете менеджмента проектов. Я так же удивлён, что ваш подход набирает поддержку в комментариях (естественно, в этом и нуждалось ваше Эго при написании этой статьи).
Проблема в том, что вы ничего не выучили из ситуации. И в следующем проекте, вангую, что вас ждёт тоже самое.
Описанная в статье ситуация - это ваше субъективное восприятие реальности.
1. 101 любого менеджемента, избавляться от предвзятости и субъективности. Это вам поможет в понимании root cause проблем управления, и принятии более взвешенных решений в следующий раз.
Как?
- Как минимум провести ретроспективу с вашей командой, с исполнителем, и с самим собой, перед публикацией подобных дискуссий.
- Как максимум - добиться root cause анализа и фиксации принятых решений в вашей практике управления.
2. Учить матчасть. Как менеджер проекта, вы не проявили не единой техники для урегулирования кризисной ситуации.
Это именно та причина, почему большинство ПМ в наше время никем не воспринимается всерьёз.
Посмотрите на ситуацию ещё раз. Каждый раз, всё что вы делали - это спрашивали "как дела" и назначали следующую дату дедлайна подсыпая её весёлыми смайликами. И каждый раз вы ожидали иного результата? Серьёзно? - Ваши Soft Skills круты, тут я соглашусь, но с точки зрения Hard Skills - это уровень выпускника старшей школы.
Менеджер должен приносить ценность в процесс работы, если он решил в ней участвовать.
Как?
- Планировать риски и уметь их митигировать.
- Транслировать идеальные даты релизов в реальные, с учётом описанных рисков, focus factor, communication overhead, etc.
- Осознавать root cause кризисной ситуации ASAP и вероятность её повторения.
- Помогать исполнителями преодолеть "человеческий фактор". Но чтобы делать это эффективно, вам, как минимум, стоит понять базу - люди уязвимы (без системы, люди не могут быть Fault Tolerant), люди не могут точно оценивать творческую работу более чем на 4ч, людям свойственно переоценивать свой focus factor, и недооценивать количество работы)
- Предсказывать optimistic и pessimistic scenarios, их причины, вероятность, и возможности ускорения.
- Повышать прозрачность, где это необходимо.
3. Судя по указанным признакам, ваш исполнитель не страдает отсутствием ответственности, но страдает технически навыками управления проектами (как и вся система целиком, в которой он находится).
Поэтому эму ничего не оставалось кроме того, как воспользоваться вашей слабостью управления, отсутствием каких-либо адекватных трекингов проектов, отсутствием прозрачности, burndown charts, соглашаясь на любые случайные дедлайны без последствий.
(Тут, пожалуйста, задумайтесь о самом слове дедлайн и его регулярных переносах. Дедлайн ли это?)
Почему?
Исполнитель никуда не сбежал. Он сдал проект с ожидаемым качеством. При этом, он крайне ответственно относился к "правкам" заказчиков по другим проектам (которые явно были не запланированы и не были перекрыты с вашей стороны).
Более того, на то конце в вас просто могли найти мамонта, с уверенностью того, что тот подождёт, подсунув перед вами ещё рад задач/заказов/проектов.
Отсутствие бесплатного овертайма - это право любого работника.
Наладка предсказуемого процесса с минимум прерываний, включая coaching и наладку системы целиком - это ваша ответственность как управленца.
Безусловно, этот скилл нужно прокачивать для развития своей карьеры.
Перекладывание ответственности на исполнителей через статьи на VC в этом не помогает.
Какой-то сюр, это не инвестор, это какой-то заговорщик микрозаймов.
24М на 2 года это только з.п. 2 девов + таксы. Какие здесь можно прогнозировать статьи расходов в пределах 20%?
Совок в голове - фаундер на дошике?
Урок со статьи один: видишь "целевой договор целевого займа" - беги, это даже близко не тянет ни на пре-сид, ни на ангела. Это смертушка.
Интересный опыт, спасибо за статью.
Что насчёт IT консалтинга? Те же яйца только сбоку, или есть ряд особенностей?
Так же любопытно, можно ли где-то в IT консалтинге заработать больше, чем в продуктовых компаниях?
На своём примере, такое не получилось. Сама индустрия и потенциальный опыт мне казались заманчивы, но оффер от Thoughtworks (топ из IT имхо) в своё время показался очень слабым ($170K/year, Senior, SF).
Ближайшие стартапы предлагали минимум X2. Решил, что нафик.
Это я куда-то не туда пошёл? Или есть всё-таки какой-то потолок в индустрии?
Выгорел 3 раза пока читал ваши скриншоты..
Не дай бог в компании увидеть лидер-борд помогаек.... о0