Я IT'шник. Мне раз в месяц предлагают поработать за "долю" в очередном говнопроекте типа приложения знакомств для левшей. В гробу я видал все эти "акции" стартапов. Платите живые деньги, кофаундеры хреновы.
В данной статье я хочу рассмотреть проблему масштабирования компаний и поделиться рассуждениями, появившимися после найденной мной аналогией в производстве, неожиданно, сыра.
Но сначала я хочу рассказать про один из способов получения новых знаний для работы - это перенос и адаптация знаний из других сфер.
Так уж получилось, что меня достаточно хаотично помотало по жизни, в течение которой я успел поработать в разных сферах и хоть преимущественно на организационных, но разных позициях, поэтому пришлось научиться извлекать лимонад из собранных кислых лимонов - это активно использовать насмотренность, используя полученные знания в одних сферах для адаптации в других.
То, что в рамках ведения проектов совпадает в разных сферах, я отношу к общей проектной теории, а что не совпадает - к специфике предметной области.
Данный прием я продолжаю использовать и внутри IT, изучая разные части проектов и направлений. Например, коммуницируя с инженерами SRE и DevOps (такие ребята, которые делают так, чтобы разрабатываемая система была стабильна, а ее новые версии поставлялись быстро и исправно), я подчеркнул для себя, как можно организовать управление инцидентами в исполнении рабочих процессов, хотя изначально эта штука была направлена на управление стабильностью систем строго в рамках DevOps/SRE, но она просто крайне универсальна.
Или другой пример, в рамках разных секторов рынка IT - если ты набрал опыта по игрострою, то ты можешь использовать такие приемы, как «геймификация» в продуктах, не являющихся играми (вспомните Duolingo - штука для обучения, но цикл ее использования построен как игра).
Наверное, я говорю о чем-то простом, и это просто называется «насмотренность», но есть в этом все-таки определенная часть, не позволяющая этой истории быть банальной - это наличие противоречий в желаниях тех, кто строит свою команду: (а) одновременно берут людей с минимально заполненной чашей знаний и навыков, чтобы было проще обучить специалиста «под себя», не тратя сил на их переобучение, и (б) хотят опытную, насмотренную команду с навыками, которые сложно получить, работая только над одним проектом.
Само по себе противоречие для любой системы - это нормально и ожидаемо, это в целом свойственно сложным системам, и это условие, которое нужно принять и учесть, выбирая способ увеличения насмотренности: нужно извлекать новые знания так, чтобы меньше сталкиваться с данным противоречием.
И хоть периодическая смена работы является самым быстрым способом набора насмотренности, особенность конкуренции на рынке труда такова, что есть небезосновательная дискредитация кандидатов, меняющих работу каждые полгода - это действительно красный флаг в резюме, который может подтолкнуть к предположению, что человек не может удержаться на одном месте долго.
Есть способ попроще, чтобы не набрать красных флагов - это менять проекты внутри одной компании, накапливая проектную насмотренность, или выбирать компании с высокой интенсивностью продуктовой разработки.
Но мы рассмотрим еще более простой способ - это искать вдохновение, новые идеи и концепции совсем не в IT, но при этом подходящие под применение в IT, на стороне, как, например, делал Алан Кэй, один из разработчиков концепции ООП (объектно-ориентированное программирование), который вдохновлялся клеточной биологией, перенося поведение клеток на объекты в программировании, и при этом у него не было образования биолога - это было просто ему интересно.
Строго говоря, это называется «метафорическое мышление» - способность находить аналогии между разными областями знаний, переносить идеи, принципы или структуры из одной системы в другую для решения задач или создания новых концепций.
Немного поясню за контекст проблемы, о которой я много думал в последнее время: за последний год мне повезло встретить больше новых и крутых специалистов, чем обычно, при этом с представлениями, которые мне раньше не встречались. Один из них, технический директор на консалтинге, имеющий много опыта работы как и за границей, так и на отечественные компании, с которым я обсуждал свои соображения по проблемам масштабирования в целом по IT (это второй контекст - я встретил много проектов, находящихся в кризисе масштабирования), и он поделился со мной наблюдениями и сравнением нашего IT с западным: «У нас инженеры сильнее, а менеджеры и бизнес - слабее».
И действительно, я вспомнил, как лет пять назад работал с одним польским издателем мобильных игр, представляя со своей стороны отечественную фирму-разработчика игр, и был удивлен тому, насколько одновременно грамотно у них поставлены процессы, и какие хреновые у них технические решения. Я тогда шутил, что это «высокоорганизационная поставка неверных решений». Т.е. хоть и от обратного, но наблюдение подтвердилось: мы, как и свойственно стране постсоветского пространства, имеем сильную инженерную часть (предположу, что это благодаря большому количеству специалистов из-за бесплатного образования), но при этом слабый организационный элемент в бизнесе (думаю, хоть мы и быстро построили капитализм, все-таки это такая история, которую сложно обогнать).
Это, конечно, типовая проблема ("стартапы vs корпорации и проблема того, как одному перерасти в другое"), но есть хоть и эмпирическое, но четкое ощущение того, что у нас эта проблема выражена значительно сильнее.
Во-первых, как будто есть такая история, где мы построили отечественную сферу IT как сферу мирового аутстафа (предоставление инженеров в аренду), где кешбеком от заказчиков возвращается преимущественно более прокаченными инженеры, а менеджеров, как правило, заказчики уже имеют в штате и обратная утечка мозгов по управленцам идет медленнее.
Во-вторых, у нас нет таких платформ, как PMI (если я это упустил, нет мне прощения - буду рад, если поделитесь) - огромная и мощная платформа по сбору и анализу знаний по менеджменту и ведению проектов, и предположу, что общая программа обучения в университетах может запаздывать к глобальной мете разработки.
В-третьих, специфика самого IT такова, что забуксовка на этапе стартапа в виде отсутствия роста компании не является тем, что ее уничтожит быстро и однозначно - у вас команда в 10 человек, 1 продукт в линейке, рост прекратился уже давно и риски потерять рынок все ближе, но вы все еще зарабатываете миллионы, хоть и стоите на месте.
Для конкретики давайте рассмотрим известный мне случай:
Условная фирма «Есть кибертемка». Условные 8 программистов под прямым управлением Овнера (owner, владелец компании) за пару лет создают на костылях продукт (что нормально для выхода на рынок), который выстреливает и очень быстро завоевывает часть аудитории, подтверждает гипотезы и обеспечивает первый поток прибыли. Точно ясно - надо точно копать дальше, дело стоящее.
Дальше стоят две задачи - обеспечить дальнейший рост, чтобы получить больше клиентов (соответственно, оставить меньше конкурентам, которые уже начали делать аналог и дышат в затылок) и, главное, заранее обеспечить конкурентное преимущество продукта - чтобы он работал стабильно (мы ведь помним, что первая версия была сделана на костылях, которое имеет технические ограничения?), имел много фич и просто не давал шанса конкурентам догнать продукт, когда их аналоги будут готовы.
Соответственно, мало того, что в команду нужны новые специалисты (продажники, рекламщики, аналитики и остальная братия, вроде кадровиков и бухгалтеров), так еще и требуется больше программистов - потому что текущие не успевают и поддерживать действующий продукт, исправляя баги из-за костыльной реализации, и одновременно рефакторить его, чтобы сделать его вообще возможным к добавлению новых фич, и при этом как-то уже сейчас добавлять фичи - потому что кто быстрей - тот и поспел на рынке.
Овнер - крайне крутой мужик, который умеет в выход на рынок, знает и потребности клиентов, и может руководить небольшой командой просто на скиллах операционного контроля, но программистов уже 60, а скоростным методом поставленных замов уже под 10 человек, а скорость разработки все падает, падает, а фич, которые нужно было выпустить уже вчера, уже не сосчитать.
И при этом из изначальных 8 программистов ушли 4, 1 ушел к конкуренту, 1 судится за авторство идеи и оставшиеся 2 борются за то, кто будет тимлидом, подставляя друг друга и не успевая рассказывать новым программистам, как этот код вообще был написан.
Потому что управление бизнесом, финансами, командой и проектами - это абсолютно разные вещи, разные направления и особенно - на разной глубине применения.
Управлять маленькой командой может почти любой, это легко - просто используй операционный контроль, давай задачи голосом, а для сбора обратной связи - ежедневные летучки, например. Задача ушла, через день информация по задаче пришла, все коммуникации прямые.
В данном случае основной орган управления в команде, когда она была из 8 программистов, - это ежедневные летучки на 15-20 минут, где Овнер давал новые задачи и получал отчеты о старых, сразу получал информацию о проблемах и разрешал их «на месте». Все слажено, все просто, все понятно.
Но уже на отметке роста команды в 15 человек ежедневные текучки затянулись на час и более, а объем одновременно разрабатываемого функционала вывел уровень информационной неопределенности до критического, управление сложностью провалено - слишком много информации и проблем, которые можно осознать за один присест.
Что пошло не так?
На самом деле, почти всё, что могло пойти не так, пошло не так, буквально каждый процесс не пережил масштабирования, но мы можем рассмотреть буквально один, чтобы понять, как это выглядит системно и насколько критичны навыки масштабирования, — это то, как организованы коммуникации, а в частности, тот самый орган управления в виде ежедневных летучек.
Когда Овнеру стало ясно, что нужно что-то менять и что главная симптоматика — это длинные ежедневные созвоны, то вместо того, чтобы управлять абстрактностью получаемой информации, он просто перевел ежедневные летучки с голосового формата на текстовый, получив вместо самого эффективного способа общения (ртом в уши) тысячи букв, которые нужно читать каждый день. Сюда же можно прибавить страх к изменению данного процесса, потому что он является единственным органом управления.
На самом деле, как я говорил, Овнер не дурак, и была причина, почему созвон со всей общей командой не был заменен на созвон только с руководителями отдельных подразделений: менеджмент был собран стихийно, повышены разработчики на основании личного доверия, а не компетенций управления, а оставшиеся руководящие позиции взяты «по объявлению», и надежда была на то, что со временем менеджмент будет дотянут до уровня, когда ему можно доверить и делегировать управление. При этом на всё это наложилось и умножилось отсутствием психологической способности к делегированию ответственности и управления.
В частности, в плане коммуникаций, даже после того, как спустя много времени, нервов и шишек была выстроена вертикаль управления, позволяющая управлять командой в 60 человек, эхо старой модели продолжала оставаться: старые разработчики, которые были «в самом начале», использовали прямую коммуникацию с Овнером, так называемые «сквозные коммуникации» через несколько голов, периодически внося хаос в условно стабилизированный процесс.
Почему же так? Всё упирается в одно: проектная модель не была готова к масштабированию, и само масштабирование не было проведено до конца, тем более что это только один этап масштабирования, а теперь представьте компанию в 4500 человек с их дивизионами, холдингами и прочей дичью громадных контор, каждый новый уровень — новый процесс. При этом, если мы выстраиваем абстрактный интерфейс управления для команды А, Б и В, то чтобы все интерфейсы могли использовать в одном новом органе управления, то процессы и структура этих команд должна быть одинаковой, иначе интерфейсы будут разными, и под каждый из них придется разрабатывать уникальное соединение с органом управления.
Соответственно, мы подходим к решению, которое и применяется в обычной мете управления: нужна проектная модель, универсальная, описанная и понятная, которую можно быстро внедрять в разные команды и проекты, с описанием этапов и алгоритмов внедрения. Также очевидно, что такие сложные системы нужно строить с ценностью, где в первую очередь стоит роль, а не личность: модель должна иметь простую ролевую систему, не привязанную к конкретным людям, потому что это ломает сам принцип универсальности и абстрактности. Проектирование таких систем должно быть максимально абстрактным и простым, избегая или минимизируя влияние человеческого фактора — фактора, который может разрушить любую систему.
Для этого, собственно, и есть куча описанных проектных моделей в прожект-менеджменте.
А при том, что всё это полная лажа - есть вещи, которым можно обучить: это правила, алгоритмы действий, описание рабочего процесса и инструкции, грубо говоря, явные знания, текстом на белом, которые можно прочитать и исполнить, построив некую систему, которая сможет масштабироваться.
Но есть вещи, которым нельзя обучить, их можно только впитать - это ценности и культура.
Ценности соучастия, являющиеся фактором облегчения развития и внедрения процессов как фактора выживаемости компании, или понимание продуктовой ценности и взаимосвязи между положением компании на рынке и объемом личной зарплаты.
Или даже что-то более метафизическое - ценности по определенным качествам коллег, позволившие данному стартапу откусить свою часть рынка, включая не только профессиональные качества, но и личностные. А так как это уже про культуру, здесь больше сложных вещей, которые можно описать - локальные истории, юмор, отношения.
Нельзя написать список из пунктов «1. Будь честным. 2. Будь соучастным. 3. Будь крутым» и надеяться, что после прочтения данной инструкции человек станет честным, соучастным и крутым - это просто так не работает, а вот кринжа вызовет достаточно, если кто натыкался на такое.
Можно научить человека двигать таску в тасктреккере, но уже несравненно сложнее сделать так, чтобы он сам хотел сделать это - нужно долго объяснять целеполагание, выгоду для всех, обосновывать выбор решения по сравнению с другими, в общем, это такой момент, который сразу виден в человеке - въезжает ли он в канву ценностей основной команды или нет.
Почему две одинаковые команды разработчиков, работающие над одними типовыми задачами, имеющие примерно одинаковый набор экспертизы, могут быть значительно разными в эффективности, инициативности, скорости обмена информацией и принятия решений - и как сделать так, чтобы одна команда стала такая же, как вторая?
Как можно передать качества, как передавать неявные знания и принципы, если эти понятия нельзя измерить, оценить и потрогать - потому что это, извиняюсь, тонкие материи - культура, мать ее.
И вот тут мы подходим к моменту, который может быть максимально очевидным при прочтении, но для меня это окончательно закрыло противоречие в обоюдно верных утверждениях, что (а) в процессах важна роль, а не личности и (б) кадры решают всё и всё зависит от конкретных людей.
На решение меня подтолкнуло то, как устроено производство сыра среди ремесленного бизнеса.
Есть некий технологический процесс, алгоритмы действий, всякая умная и хитрая техника, которой надо уметь пользоваться, и всё это заменяемо и изменяемо, кроме одного - закваски, которую использует мастер.
Некая колония микроорганизмов, выведенная лично им, находящаяся буквально в одной банке в течение всего времени существования ремесленного предприятия и катастрофически влияющая на вкус итогового продукта, делая его уникальным и обеспечивая узнаваемость сыра конкретного этого мастера.
Причем мастер может сохранить продукт, если сгорит мастерская, сломаются приборы, сменится исполнитель - ничто из этого критически не изменит вкус, если дрожжевая закваска осталась та же, что и была всегда.
При этом ее объем восполняется - колонию подкармливают питательными веществами, и самое главное - дрожжевую закваску можно разделить на две идентичные банки, восполнив и восстановив их объем тем же питанием.
Мы получаем две банки с условно идентичными колониями микроорганизмов, дающими в итоге один вкус сыру, делающими одинаковый продукт. Минимальное расхождения генома и идеальный пример масштабирования - взяли что-то единое, разрубили на две части, откормили обе части, и вот - у нас две одинаковые сущности. И при этом нам не пришлось постигать тайны генетической модификации, получать ученые степени и улавливать тонкие материи, мы тут просто закваску рубим.
Думаю, читателю уже очевидно, к чему я вел.
Недостаточно просто иметь проектную модель, подготовленную к масштабированию с документацией процессов и инструкциями, нужно найти способ передавать и неявные штуки, вроде культуры и всякой тонкой материи, которую сложно уловить.
Помимо этого, критически важна первая, изначальная команда. Первую команду нужно организовать с максимальным вложением сил, отсортировывая и воздействуя, пока еще есть возможность влиять и доносить ценности напрямую, от души в душу, короче.
Первая команда, чей набор ценностей будет эффективен, должна стать дрожжевой закваской, а все будущие команды мы уже отпочковываем от них, не нарушая изначальный состав. Давайте назовем это подразделение «зиро-команда»: зиро-команда должна представлять из себя минимальный набор ролей и экспертизы, который нужен будет во всех следующих скопированных командах.
Как это сделать на примере? Пусть будет тимлид, тест-лид, ведущий аналитик, несколько ведущих инженеров, уже поставленные процессы и устоявшиеся конвенции. Временно увеличиваем зиро-команду, допустим, в полтора раза, добавив руководителям замов, а ведущим специалистам напарников для парного программирования.
Добавляйте постепенно, чтобы масса новоприбывших поступала равномерно, по одному или два, чтобы их объём единовременно не стал критическим и не превратился в новую точку кристаллизации и исход новых ценностей. Запускаете в объёме, который может переварить и перепрограммировать старая команда. Надеюсь, мой подбор формулировок вас не испугал — я говорю про сохранение ценностей и особенности поведения людей при интеграции в новые коллективы. Негативные примеры вы можете увидеть при плохо поставленной порционности прихода иммигрантов — они не интегрируются, а строят анклавы, если приходят большими группами и без процессов интеграции в общество.
Люди — существа социальные и на самом деле вполне склонны к усвоению негласных правил и уставов в монастыре, если только их за раз не приходит слишком много, чтобы иметь возможность переписать действующий устав.
Дайте время порции новоприбывших интегрироваться в процессы, всосать культуру, юмор, ценности и правила, дайте время на отбор и замены.
Далее — отпочковывайте новеньких в отдельную команду под временным арбитражным управляющих из зиро-команды. Проще всего обеспечить это, дав задачи командам в одной зоне работы, разрабатывая модули с отношением «включая», например.
Через время убирайте арбитражное управление и подсоединяйте команду к общему органу управления, чтобы этого у вас не было — команды должны быть равными и иметь прямые линии управления из одной точки.
Поздравляю, у вас две команды.
Да, способ, который я описал, медленнее обычного масштабирования, когда мы описываем некоторую проектную модель и можем сразу, одновременно строить множество подразделений, но в таком случае не будет скопирована культурная ценность, расхождения будут приходить все быстрее, в отличие от копирования через дрожжевую закваску в виде зиро-команды, потому что это связь из разряда «один к множеству», а не «множество к множеству», как в классическом способе.
Тем более, что касается скорости масштабирования — как правильно, это не история того, что масштабирование шло медленно, это история того, что масштабирование **было начато поздно**, а все остальные негативные случаи — это как раз то, когда масштабирование происходило слишком быстро, и команда просто не успевала адаптироваться.
Можно делать медленнее, последовательно, через зиро-команду, если этот процесс налажен и дает нужные результаты. Более медленную историю интеграции процессов проще контролировать.
И, разумеется, я не претендую на открытие — так делают, делают это интуитивно или по рекомендациям в связанной литературе, но я хотел поделиться собственными рассуждениями, аналогиями и, наконец, осветить важный аспект:
Масштабируйте не только команды и проекты, масштабируйте ценности и культуру!
В последний год бакалавриата в НИУ-ВШЭ главной проблемой всего студенческого сообщества было решение, на какое направление магистратуры пойти. В тот момент я для себя решил пойти на страт менеджмент. Программу управления проектами я считал скукой смертной и историей вообще малоприменимой.
Штука в том, что на протяжении всей моей дальнейшей карьеры (а это почти 14 лет)
независимо от того, в какой функции и роли я работал, изрядную долю времени занимали именно проекты: новые запуски, тесты материалов, стройки века, интервенции с поставщиками.
Жизнь меня быстро научила, что или ты оперативно познаешь искусство проджект менеджмента, или будешь болтаться в неуправляемом хаосе задач, который рано или поздно выйдет из-под контроля и даст тебе по затылку. В статье я буду говорить о том, как это искусство использовать, но делать это с умом и высокой полезностью.
Что меня поражает, так это то, что многие мои коллеги и партнёры упорно забивают на простые и доступные инструменты и стараются управлять проектом силой «мышц». Как итог: безумные трудозатраты, отсутствие ясности действий, сорванные сроки и ярость вовлечённой команды. Что я стараюсь добиться от своих команд — использования простых базовых инструментов:
Project charter (он же устав проекта)
Диаграмма Ганта (план)
Трекинг и драмбит (прогресс)
Эти инструменты позволяют держать проект под жёстким контролем, адаптироваться под изменения и избежать излишнего стресса как исполнителя, так и всей команды.
Я пишу (в том числе на своем канале) только про те инструменты, которые я использую (и всем рекомендую) и которые позволяют мне запускать инициативы разной степени сложности и креативности.
Меня вгоняет в священный ужас то, как упорно люди не хотят использовать доступные инструменты, чтобы упростить себе жизнь. Вместо этого собираются бесконечные совещания, пишутся письма, назначаются кризисные коучи. В итоге всё делается в стрессе и «вопреки». Зачем эти муки — мне непонятно. Я считаю, что основы Project Management должны быть в любой организации, неважно, большой или маленькой. Без них любое дело превращается в неуправляемый хаос, который рано или поздно треснет тебя по голове.
Хорошо составленный, продуманный и одобренный чартер сильно помогает разрулить проблемы до их возникновения. Из последнего опыта работы над проектом без этого этапа — полный хаос и бардак. Поверьте, это супер неудобно в середине проекта бегать и выяснять, где бы найти дополнительного инженера или как вовлечь специалиста, который знать не знал про ваш «самый важный и нужный проект».
Есть обязательный набор элементов, которые должны быть в любом чартере, чтобы потом не пришлось страдать во время реализации.
Название. Может показаться надуманным, но с названия всё начинается. Если оно скучное/стремное — народ даже называть проект не захочет. Поэтому, заморочься и придумай что-то классное и вдохновляющее. Самому будет приятно.
Лидер. Чтобы всем было понятно, кто отвечает за проект end to end. Главное контактное лицо и точка сбора всей информации. По факту — временный директор всего мероприятия, которому должны подчиняться участники. Важно, чтобы все (включая менеджмент) понимали, кто это, с какими вопросами к нему/ней ходить и понимали, что этот человек — реально главный.
Участники и их роли. Дарует понимание, кого вовлекать, когда и зачем. Позволяет максимально эффективно распределить задачи и не получить «сюрприз» в последний момент в виде отсутствия человеческого ресурса для выполнения той или иной задачи. Особенно это опасно в крупных проектах, где вовлечено большое количество функций и департаментов. Но даже в небольшом проекте, при непродуманном составе участников и без чёткого распределения ролей, можно нарваться на непроходимую стену, потому что человека просто нет.
Цели, деньги и KPI. Зачем мы всё это делаем? Сколько стоит? Какой бюджет? Что считать успехом. Краткая формулировка и цифровые измеримые показатели. Не можешь сформулировать — не начинай делать. Проект важно не только сделать, но и закончить (формально). А если не будет в голове у всех единого понимания, какие результаты считать успехом, то можно попасть в ловушку «вечного проекта».
Стратегия коммуникаций. С кем, как часто и о чём будете говорить. Как часто давать отчёт топ-менеджменту. В больших проектах чёткое расписание коммуникаций необходимо. Иначе будут приходить все подряд с вопросами "ну чё там" и "дай апдейт". При плохой коммуникации даже самый классный проект может превратиться в кошмар.
Риски. Указание слабых мест и как с этим бороться. Важно подсветить на берегу и продумать, что делать если…
Кто одобряет. Секция для того, чтобы большие начальники дали своё ОК на всё вышеизложенное. Они решают: выделят или нет запрашиваемый ресурс, радуют ли их KPI, согласны ли с бюджетом. Получи их подтверждение и в любой спорной ситуации с командой на руках будет козырь.
Короче, документ ооочень нужен до старта любого проекта, чтобы определить правила игры, и чтобы всё пошло гладко, а не через немогу. Материалов и форматов в интернете — огромное количество. Важно инвестировать в него достаточное количество времени, так как подготовка — 80% успеха.
Честно - это моё спасение, которое вкупе с краткосрочным action plan помогает управлять самыми безумными инициативами. Самый прикол, когда начинающие менеджеры проектов пытаются все действия отследить ....в письмах. Ну ок, если действий десять, а если сто? Представьте, как выглядит этот манускрипт? И главное, насколько им удобно пользоваться. Я в таком участвовал. Понять, что происходит на третьей неделе проекта стало просто невозможно.
Диаграмма Ганта представляет собой визуальное отображение всех этапов проекта на временной шкале. Да, вот так просто. Никаких нанотехнологий, нейронок и сложных систем. Бывает high, mid и low level, где high — основные крупные этапы (подходит для ревью с топ-менеджментом), low — поэтапная разбивка задач (используется, чтобы не упустить ничего рабочей группой).
Диаграмма работает (и задизайнена) очень просто: первый столбец — задачи, второй — ответственный. Третий и далее — временная шкала с равномерным шагом (я предпочитаю одну неделю, хотя когда находились на последних неделях пуска - переходили на ежедневную гранулярность). Получается своего рода матрица «задача Х время», которую закрашиваем в зависимости от сроков каждой задачи.
Мозг проджект менеджера особенно нужен, чтобы вместе с командой понять, какие задачи могут выполняться параллельно, а какие последовательно. Например, монтаж оборудования и обсуждение логистического плеча могут выполняться параллельно. А вот монтаж оборудования и его пусконаладка — только последовательно (исключая особо креативные кейсы).
Важно определить элементы критического пути, то есть те, которые сдвигают весь проект при изменении сроков. На них, естественно, максимальный фокус и попытки сократить. Например, без того как приедут нужные компоненты, ты хоть тресни - не начнешь тесты своего продукта. Чем дольше едет - тем позже все начнется.
План нужно регулярно отслеживать (см. следующий абзац про Стратегию коммуникаций) с нормальной и понятной цветопередачей: жёлтый — запланировано, зелёный — сделано, красный — просрочено. Тут нужен фанатизм и дисциплина. Первые ревью будут долгими с криками и стонами. Не реагируй, а делай (ну и объясняй, зачем). Потом всё пойдёт ровно.
И да, вся игра с цветами и раскрашиванием статуса очень нужна. Мы визуально отслеживаем, что идёт так, а что нет. Многие допускают ошибку и игнорируют это упражнение. В какой-то момент глаз что-то не улавливает, и мы пропускаем пункт, который по принципу домино разрушает всё вокруг.
Сделать план проекта можно самостоятельно в Excel, скачав шаблон Excel (например, шаблон диаграммы Ганта) или используя специальный софт, например, MS Project (но он платный). Из условно бесплатного (до пяти пользователей) можете попробовать YouGile — классный онлайн-ресурс. Сам я использую его для личных проектов. Учти, лучшее — враг хорошего. Не надо для относительно простого проекта юзать сложный софт — потратишь больше времени на поддержку. Но запомни: чёткий и визуально оформленный план нужен всегда.
Прям как на кораблях в старые времена: проджект лидер берет барабан и задает темп. На самом деле, не все так просто. Чтобы не ассоциироваться с попугаем, который бегает ко всем по кругу и спрашивает «ну че там» (частое явление, к сожалению), необходимо выстроить четкую систему встреч, с жесткими временными рамками, повесткой, составом участников и ожиданиями.
Помните про чартер? Все все встречи, частота, тайминг, участники, должны быть прописаны уже там. Тогда не будет рассуждений: кто куда должен ходить и зачем. Иначе, придя на очередную встречу, обнаружишь там полтора человека, и потом будешь бегать и собирать информацию со всех, кто не пришел.
А чтобы всего этого не произошло - Фиксируй правила игры / встречи (в идеале пропиши). Я делаю очень просто: все приходят вовремя, ответственные за действия - с готовым апдейтом. Если сделано - отлично, не вдаемся в обсуждение. Если проблема - обсуждаем и ищем решение. Это помогает избежать долгих и ни к чему не приводящих дискуссий.
Встречи должны быть сфокусированы на конкретных действиях, каждая должна заканчиваться коротким и четким письменным резюме. Кстати, для многих написать резюме - сложнее, чем отправиться в путешествие, зарубить дракона лопатой и спасти принцессу. Специально нам в помощь нейронки могут превратиь хаотичный текст записей во вполне удобоваримое резюме. Короче, надо чтобы понятно, какой выхлоп и следующие шаги встречи.
А чтобы это все выполнялось - веди срочный план действий. Помимо диаграммы Ганта (которая покрывает весь проект) создай отдельную вкладку (документ, файл, что угодно, но простое) с краткосрочным action plan. Это то, что команда должна сделать в ближайшее время (1-3 дня). Структура простая: действие, ответственный, срок, статус (done/in process/ delay)
Чтобы резюме встречи не превратилось в боль для тех, кто это читает - используй план действий как резюме встречи. Не усложняй. Никому не интересно читать простыню текста. Если сразу нормально онлайн сделал план - скопировал и вставил.
Указывай ответственных и сроки. Сам бери ответственность (не только руководи). За сроки спрашивай. План без сроков и ответственных - фигня. И, пожалуйста, не плоди файлы. Я не заморачиваюсь и веду чартер, план, драмбиты в разных вкладках одного файла
Высылай резюме сразу, чтобы люди могли работать по обговоренному плану. Выслав план и договорившись о действиях, не напрягай людей вне согласованных встреч и таймингов. Это отвлекает и вообще невежливо.
Ну и последнее, про что все забывают. Празднуй промежуточные достижения. Команде важно видеть победы. Команда в стрессе работает плохо.
NET или вместо итога: статье я изложил очень краткую выжимку (и да, она краткая) того, что реально помогает вести и выполнять проекты в совершенно реальном, а не в теоретически смоделированном бизнесе. Этот инструментарий помогает вести и закрывать проекты эффективно и чаще всего раньше сроков, с наименьшими заморочками, страданиями и проблемами. Тема, естественно, обширнее и сложнее и познается через практику, как и все в бизнесе. Главный совет, который могу дать, исходя из многолетней практики - начинайте пользоваться инструментами, которые доказали свою работоспособность и полезность.
Если статья понравилась - еще больше подобного материала на моем канале.
Итак, я — бывший «счастливый» обладатель PMP-сертификации. Почему «бывший»? Потому что, честно говоря, я выучил ее, сдал экзамен и… забыл как страшный сон. Объясню, почему.
Ну, как-то так...
Когда я готовился к PMP, меня буквально заставляли зубрить PMBOK. Шутка ли — передо мной лежала книга, в которой была куча схем, процессов, странных терминов и совершенно надуманных кейсов.
Читал и думал: «Реально ли это использовать в моих проектах, в реальном — не придуманном — мире?»
В нефтегазе, EPC и горно-рудных проектах всё иначе: постоянно всплывают новые вводные, у заказчиков меняются приоритеты, сметы проседают, подрядчики ведут себя по-своему.
А PMBOK Comics (я по-доброму называю его «комиксом», потому что схем там больше, чем в любом учебнике по логистике) словно из параллельной вселенной. «Делай процесс А, потом процесс Б, а дальше рисуй матрицу ответственности на десяти страницах». Серьёзно?
Сертификация PMP сама по себе преподносит чудо: выучишь, сдашь — и станешь супер-управленцем. Но в реальности она даёт (в лучшем случае) стандартные инструменты, которые хорошо бы работали… да, наверное, где-то в уютной «лаборатории PMI» или в компаниях, которые строго следуют канонической методике.
Однако, когда у вас горит подряд на стройплощадке в -40°C, меняется состав бригады, неожиданно слетает поставка оборудования, а ещё, как назло, нужно «вчера» найти новую бригаду сварщиков — «универсальный» план по PMBOK может подвести. Потому что он не адаптирован к такому хаосу.
Когда я готовился к PMP, я потратил кучу времени (и денег) на курсы, мок-тесты, нервы и бессонные ночи. Убедил себя, что «без этого сертификата — я не специалист». Но когда всё закончилось и я вышел с тем самым “Pass” на экране, возник вопрос:
«А что теперь? Где волшебное улучшение моих реальных проектов?»
Окей, была строчка в резюме, которая вроде бы впечатляет рекрутеров. Но в практике — те же проблемы, и не решаются они на автомате (увы!).
Я искренне пытался применять «методологии из книги». Но всякий раз, когда меня заносило в реальные проекты (особенно крупные EPC, нефтегаз, строительство), приходилось импровизировать.
Технадзор озверел
Задержка в связи с требованием откатов у Заказчика
Поставщик задержал контейнер на границе.
Появились новые требования заказчика.
Вместо «страшного сна» из бесконечных процессов было эффективнее использовать то, чему меня учила жизнь: обсуждать и договариваться, находить быстрые обходные пути, подключать личные связи, перестраивать график на ходу и не забывать про реальных людей, а не только про «stakeholders» на схеме.
Я не говорю, что PMP не имеет никакого смысла. Может, в идеальных условиях, где-нибудь в идеальных условиях США и Канады и помогает систематизировать подход. Может, кому-то нравится структура и терминология.
Но мой опыт говорит: если проект нестандартный, меняется каждые пару дней, а реальность жёстче, чем рекомендации в книжке, приходится опираться прежде всего на «боевые» знания.
И я понял, что наибольшая ценность, которую я вынес из подготовки к PMP, — это, пожалуй, умение по-другому взглянуть на планирование. Но всё остальное — ух, проще сказать: «Не знаю, не помню, пошёл импровизировать».
«Кому всё-таки пригодится?»
Тем, кто работает в средах, где действительно внедрены классические процессы PMI (или, по крайней мере, HR настаивает на этой сертификации для повышения в должности).
Тем, кому нужна «бумага» для резюме, чтобы пройти фильтр рекрутеров в консалтинге или крупной корпорации, где все «по учебнику».
Но если вы по уши в производстве, стройке, горнодобыче или на лютом узле нефтегазового проекта, PMBOK может казаться далёкой небесной теорией.
Не бойтесь, но и не ждите чуда. Если хотите, получите её — это личный выбор. Но будьте готовы: в реальном «поле» придётся включать мозг, а не просто соблюдать «процедуры из комикса».
Импровизация, умение быстро переключаться, налаживать коммуникацию с людьми — вот, что работает там, где нет идеальных условий.
PMP — часть большого мира инструментов, но не замена вашему опыту и навыкам.
Я — человек, прошедший через это, и могу сказать только одно: лучше учиться у реальных проектов, чем слепо верить тому, что написано в PMBOK. Не бойтесь выйти за рамки и применить то, что действительно работает «здесь и сейчас». Пускай PMI остаётся в своей лаборатории, а мы с вами — в реальности.
Частая проблема, о которой спрашивают менеджеры — недостаток производительности команды, которая на первый взгляд загружена важными задачами.
В таких ситуациях нужно абстрагироваться от личного восприятия и обратиться к цифрам. Потому что не исключено, что нет никакого андерперформинга, а это менеджер задрал планку и наводит лишнюю суету.
Так что изучаем метрики и убеждаемся, правда ли команда не перформит. Если метрик нет, их надо определить, а уже потом делать выводы. Иначе это только мнение. А мнение — не факт.
Второй момент часто заключается в отсутствии понимания. Спросите себя:
- Есть ли у членов команды ясность, что от них ждут?
- Чёткие ожидания?
- Конкретные цели?
Не сможете ответить на эти вопросы — поймете, почему команда недорабатывает. Если люди бродят в тумане и не понимают, что и зачем делают, они не виноваты, что не дают результат.
Поэтому задача на этом этапе — добавить конкретики. Например, четко описать ожидания по роли и обязанностям каждого участника команды.
Если во всех вышеперечисленных факторах проблем нет, возможно дело в недостатке навыков, ресурсов для работы или обучения. Айтишные проекты требуют высокой компетенции, будь то кодинг, проектирование или тестирование. Поэтому проанализируйте, есть ли у людей навыки, чтобы соответствовать? Если нет, помогаете ли вы им в части обучения? То же касается инструментов и организации рабочего пространства.
Банальный пример: у команды может криво настроен таск-трекер (или его тупо нет). Как результат, задачи теряются и возникают форс-мажоры. Что делать? Настроить задачник, чтобы им было удобно пользоваться, и все будет ок.
Если ничто из этого не является проблемой – то есть это не вина менеджера или компании, – обратите внимание на самих людей. Есть куча вводных: благополучие, демотивирующие факторы, внутренние и внешние мотиваторы, эмоциональный интеллект и т.д.
Возможно, вы давно буксуете в одном проекте и глаза замылились. Или в мире очередной пиздец случился и пока не получается перформить как раньше. А может, в компании что-то изменилось и нужно время на адаптацию.
Не важно, в чем дело – наша задача слушать и поддерживать. Если люди чувствуют, что их не осуждают, они будут честны, и найти коренную причину проблемы станет проще. А если искать виноватых и устраивать разборы полетов, сперва это может и сработает, но потом все разбегутся.
Еще каких-то пять лет назад наши менеджеры сидели на зарплате, были счастливы и не думали, как с технической стороны объяснить клиенту, почему сдвинуть кнопку может стоить 20 баксов.
Пока не пришлось резко повзрослеть: обзавестись собственным мини-бизнесом внутри компании с долей от прибыли и правом решать, как жить дальше. В статье расскажу, как отбирал этих отважных людей, чему их учил, и почему теперь я сам хожу по офису, кланяюсь и спрашиваю, не угодно ли им кофе.
Меня зовут Дмитрий Хоружко, я основатель агентства по веб-разработке Nineseven
Nineseven.ru специализируется на разработке и поддержке интернет-магазинов для крупных e-commerce проектов. Агентство существует уже 14 лет и за это время пережило немало перемен. Мы открылись в 2010 году, начав работу командой из трех человек и 563 долларами начального капитала, а наш первый офис был всего 5 кв. метров.
Сначала работа агентства была построена хаотично: мы брали заказы на бирже, а бухгалтерия велась в записной книжке. В 2012 году начали появляться первые небольшие белорусские заказчики, а с 2013 года пошел ощутимый рост. Мы все еще концентрировались на дизайне, но стали активнее браться за разработку. Однако проблема с финансовым учетом все еще не была решена, а с позиционированием и продажами дела шли плохо.
Постоянного потока клиентов и долгоиграющих проектов у нас не было. Заказчики приходили и уходили. Наша работа была похожа на финансовую пирамиду — минусовые проекты перекрывались оплатами с новых.
В 2018 году меня пригласили поработать в блокчейн-проекте. Я стал руководителем команды разработчиков, отодвинул Nineseven на второй план и плотно работал в проекте два года.
К 2019 году «успешный и автономный» бизнес Nineseven практически испустил дух без моего надзора. На зарплаты не хватало 10 000 долларов. Я собрал команду в офисе и сказал, что практически всем нужно уволиться — сейчас денег нет, но потихоньку будем рассчитываться. Так штат из 15 человек сократился до 4, остались только менеджеры. Офис из кареты на 120 квадратов превратился в тыкву на 32.
После этого настало время реформ. Мы отменили зарплату менеджерам — теперь они получают часть от прибыли, которую генерируют для компании, а дизайнеров, разработчиков и других исполнителей перевели на работу с почасовой оплатой. Я написал софт для финансового учета, где вносится дебиторка, кредиторка, а менеджеры формируют отчеты и могут сами себе посчитать зарплату.
В дизайне я разбирался больше всего, поэтому на старте тащил одеяло в эту сторону. Думал, достаточно просто нарисовать хороший дизайн. Это работало, но приходилось палками выбивать из остальных подрядчиков, чтобы финальная версия сайта выглядела так же, как отрисованный макет.
Раньше была нормальная история, когда приходил клиент и жаловался: «Вот, мне нарисовали дизайн, а после продакшена получилось совсем другое!» — шрифты поплыли, пропорции элементов не те.
Также дизайн — это история про разовые проекты. Заказчику не нужны постоянные доработки и поддержка. Получил результат и ушел. Приходилось постоянно генерировать поток клиентов, чтобы хоть как-то выживать. Анализ проектов показал, что интернет-магазины — самые долгоиграющие проекты, поэтому фокус сместился на разработку и работу с конечным продуктом для клиентов из e-com. Мы сделали упор на наш опыт в e-commerce проекте МТС.
После этих реформ 2019 года мы начали расти и увеличили оборот с 300 000 до 700 000 долларов к 2023 году.
Однако на этом наши изменения не закончились. «Под капотом» работы команды оказалось еще немало проблем.
Изучая верстку и программирование, я понял, что проблема в первую очередь не в исполнителях, а в том, что каждый дальше своего участка не смотрит — не знает, что происходит на других этапах, потому не понимает, как подготовить свою работу для передачи на следующий этап. Более того, команда не умеет друг с другом коммуницировать.
Дизайнеры не разбирались в технической части верстки. Дизайнер рисует макет с опорой на вводные заказчика и свою узкую специализацию: типографику, теорию цвета, композицию. Но в веб-дизайне также важен инжиниринг всей системы, потому что далее макет идет на верстку.
Многие дизайнеры про верстку знают минимум — могут отличить друг от друга тег <table> от <p>. Большинство слабо представляет, как строятся сетки в CSS и что получится при переводе нарисованного макета в HTML-разметку.
Для некоторых дизайнеров даже сейчас будет магией узнать, что меню сайта в десктопной версии не трансформируется в мобильное меню, а верстаются два разных меню, и CSS решает, какое показывать в зависимости от ширины экрана
Далее макет попадает в руки верстальщика. Верстальщик пытается сделать из этого веб-страницу. Если в десктопе еще получается сделать, то могут возникнуть сложности с адаптацией для мобильных устройств или с разметкой текста. Например, отступы у заголовков должны быть заданы сквозной системой на весь проект, а дизайнер от страницы к странице рисовал отступы на глаз, потому что это быстрее, чем строить вертикальную сетку и соблюдать ее.
Или например, приходит верстальщик Pixel Perfect. Его задача — сделать так, чтобы верстка совпадала на 100% с нарисованным макетом. Если он сделает все по уму и унифицирует отступы для всех страниц, то к нему придет менеджер и скажет, что они не совпадают с отступами на макете, и верстальщик такой — ну окей, сделаю как у дизайнера. Из-за таких ситуаций верстальщику приходилось делать множество версий заголовка для каждой страницы.
Так выглядит наложение макета от дизайнера на сверстанный сайт при проверке Pixel Perfect верстки — при несовпадении элементы плывут
Теперь все это нужно перевести в код. Задача программиста — перевести в код то, что нарисовал дизайнер и подготовил верстальщик. На выходе должен получиться темплейт для системы управления сайтом.
Тут у программиста начинаются проблемы с версткой. Например, у системы «Битрикс» единая структура шаблона, которая состоит из трех частей: header, footer и body.
Грубо говоря, header — это шапка сайта, footer — подвал, ну и body — наполнение посередине. Исходя из этой структуры, у программиста есть требования в разработке, чтобы в дальнейшем упростить поддержку сайта.
К требованиям относится то, что шапка и подвал на всех страницах не должны отличаться по разметке, а верстальщик про это не знает! На своем этапе работы с макетом он может на каждой странице сверстать шапку и подвал по разным структурам. В результате это оказывается большой головной болью для разработчика, которому приходится создавать костыли, чтобы неоптимальную структуру верстки положить на «Битрикс».
Каждый висит в своих задачах и не хочет бегать к программисту и спрашивать: а как надо, как тебе будет удобнее. По сути, они и не должны этим заниматься — у исполнителей есть задачи, и они их выполняют.
Проблему между этапами нужно было решать, потому что она сильно тормозит процесс, тратит время, нервы, деньги и сказывается на конечном результате.
Для решения этого момента я поставил себе три задачи:
Разобраться, в чем заключается работа каждого этапа и отдела
Выявить, какие проблемы есть у каждого
Выработать систему, чтобы свести эти проблемы на минимум
Я разобрался с задачами — изучил, оцифровал данные, сделал чек-листы для отделов, провел парочку воркшопов с дизайнерами, верстальщиками, программистами. Но по итогу внедрил менеджеров проектов — за конечный продукт и коммуникацию стали отвечать именно они.
У руководителя в работе пул из трех-пяти проектов и своя команда верстальщиков и разработчиков. С этой командой он постоянно на связи и поддерживает ее в рамках проектов. Руководитель принимает макет у дизайнера, дает правки, передает верстальщику адекватную версию макета — так на каждом этапе.
Руководитель проекта должен быть технически подкован. У него есть чек-лист, в котором написано, что, допустим, HTML-разметка в тегах head и body до тега h1 не должна отличаться. Как он это проверит? Скорее всего, никак, если у него нет каких-либо технического бэкграунда или понимания, что вообще такое тег, из чего состоит HTML-документ.
Если он не понимает суть требования, а просто пытается механически проходиться по этим чек-листам, то магии не случится — должен быть какой-то контроль качества. Это возможно, если человек понимает, зачем это делается — только так можно на совесть оценить работу на каждом этапе.
Поэтому я решил обучать менеджеров, чтобы они тащили свою команду с пониманием дела. Только так удалось ускорить работу и в целом повысить эффективность команды. Потому что когда менеджер занимается почтальонством а-ля «клиент сказал, что у вас тут блок съехал, я просто вам принес эту новость, разбирайтесь сами» — у разработчиков появляется скепсис, что менеджер у нас просто в качестве мебели присутствует, могли бы и напрямую пообщаться.
Планирование и время. Важно не забывать про встречи, уметь работать с календарем, делать какое-то прогнозирование.
Риск-менеджмент. Разработчики чаще всего переоценивают свои возможности и называют слишком короткие сроки — нужно оценивать сложность задач и закладывать время для страховки. Может оказаться, что работу, которую обещали сделать за 10 часов, сделают за 24.
Стрессоустойчивость. Могут попасться эмоциональные клиенты — все-таки мы работаем в сфере услуг. Если менеджер не сдерживается, далеко он не уедет.
Клиентоориентированность. Я всем менеджерам говорю о том, что зарплату плачу не я, а клиенты. Потому что у нас все менеджеры получают зарплату в виде процента от прибыли.
Разбираться в этапах разработки на уровне джуна. Подробно об этом я расскажу дальше и покажу примеры тестовых заданий. Коротко: нужно понимать, как устроена работа в Figma, «Битрикс», понимать, какие нюансы могут возникнуть на каждом этапе.
Понимать архитектуру проекта. Где хранятся данные, как выглядит структура базы данных, как работает кэш, какие есть периодические задания, что такое crontab, что такое операционная система, что такое SSH, как работает Git, зачем нужны репозитории, хранилища и так далее.
Я разработал систему отбора по техническим навыкам. Для найма нужных людей было важно, чтобы каждый попробовал получить ощутимый результат или хотя бы опыт на каждом из этапов, сделав это своими руками.
1. Собрал базу знаний для кандидатов. Документы и курсы, откуда можно почерпнуть знания о процессе и выполнить практическое задание.
2. Продумал задания. Они не должны быть сверхсложными, но достаточно углубленными, чтобы человек понял суть этапа, с какими инструментариями работают спецы, с какими нюансами и тонкостями имеют дело.
3. Определил, как буду оценивать работу. Я не требовал, чтобы менеджер отрисовал полноценный макет, но он должен знать, как выглядит Figma, где эти макеты рисуют. Как в ней можно управлять макетом, как работает система слоев, компонентов и так далее.
Первое задание: построить схему макета в Figma. Можно было выбрать произвольную тематику: сделать себе визитку, схематично отразить рандомный сайт.
Условный макет сайта
Второе задание: сверстать макет. У меня уже был удобный с точки зрения верстки дизайн-макет: условно, слайдер на всю длину, немного текста, внизу текст в два ряда, табличка. Задача была — собрать на HTML структуру, сделать CSS-верстку и макет, но без использования JavaScript, потому что это другой уровень сложности.
Требований к Pixel Perfect тоже не было. Основная задача менеджера — повторить хотя бы на 90% то, что было нарисовано
Для понимания сути верстки: вкачестве подготовки рекомендую пройти базовый курс по HTML, который даст понимание, что такое верстка, CSS, как строятся блоки. Такие знания можно получить совершенно бесплатно. Например: курс по HTML
Третье задание: перевести макет в код на «Битрикс». В качестве вводных у меня был простенький шаблон текстового сайта. Нужно было сделать несколько страниц на системе управления «Битрикс»: создать темплейт, сделать нарезку header и footer, и в body подключить несколько простеньких компонентов, вроде news.list, news.detail, настроить пагинацию и несколько менюшек.
Допустим, вывести страницу списка новостей, деталей и передать мне ссылку, чтобы я ее просто проверил. Для тестового также рекомендовалось пройти курс Content Manager Bitrix: изучить возможности админки, как она выглядит, немного изучить программную часть.
Финальный этап: собеседование. По итогу всех тестовых хотелось увидеть, что у человека появилось понимание, в чем заключается хотя бы практическая часть работы, и какой результат дает каждый спец.
Сейчас у меня базовым требованием для проджектов является умение работать в серверной консоли по протоколу SSH: знать команды, уметь в Linux зайти в какую-то директорию, отредактировать файл, перезагрузить веб-сервер и так далее.
К этому можно добавить еще историю работы с табличками в базе данных, знания простейших команд — SELECT, INSERT, DELETE, чтобы он мог построить какой-то запрос, посмотреть данные.
Поэтому мы периодически собираемся пару часов на тематических воркшопах. Это может быть разбор работы с SQL, работа по SSH или Docker. По SQL, я рассказываю вводную часть, потом мы заходим в интерфейс баз данных, объясняю, что такое джойны, как делать селекты. Пробуем создать таблички и добавить в них что-то или удалить. Далее смотрим, как выглядит хранение данных в базе данных CMS Bitrix. За пару часов специалистом по базам данных не станешь, но появляется какая-то база и понимание как это устроено.
После воркшопов менеджеры могут консультировать клиентов и решать мелкие задачи руками.Например, когда приходит клиент и сообщает о поломке, менеджер понимает под капотом, как это должно работать. Он может открыть консольку, посмотреть коды ошибок, понять — проблема на фронте или на бэке, сразу сформулировать проблему, поставить задачу на нужного специалиста и договориться с тимлидом, чтобы он присмотрел.
Важная оговорка: на проектах, где используются фреймворки, какая-то кастомщина, у нас есть тимлиды, которые решают архитектурные вопросы.
Ребята работают внутри своих команд, с проекта на проект не прыгают. Когда недостаточно нагрузки, допустим, у дизайнера, то он берет в работу задачи других команд. Программисты же чаще у каждой команды постоянные, проекты плюс-минус тоже.
У нас полностью открытая система по деньгообороту: команда знает, сколько стоит каждый программист и сколько нам платит клиент. Поэтому сотрудники ежемесячно считают себе зарплату, подают мне счет, я его валидирую и выплачиваю.
Проджекты могут инициировать дополнительные продажи. Могут что-то клиенту предложить, или, если не хватает рук, начать поиск еще одного разработчика в команду.
То есть они могут просто мне сказать: «Слушай, я там двух разработчиков на проект поставил. Бюджеты с клиентом согласовал, баланс посчитал, в план по дебиторке поставил. Мы в плюсе».
У нас очень хорошие зарплаты по рынку. Был проджект, который заходил в компанию стажером и получал 300-400 долларов. Сейчас он получает в 5 раз больше.
С профессиональным ростом сложнее. Ребята как нажратые коты уже засели на постоянных проектах, которым с нами комфортно. Как с этим бороться и нужно ли — я не знаю. Тут единственная опасность, если комфортный стек клиентов в какой-то момент отваливается, менеджеру будет больно, так как придется включаться в новые проекты с нуля.
При этом свои навыки они прокачивают. Проекты и клиенты разношерстные — каждому нужно свой опыт, под каждого нужно подстраиваться, все время появляется новое и непонятное.
Основная команда менеджеров состоит из 5 человек, Паша и Юра с нами дольше всех. Паша пришел в ноябре 2016 года, а Юра на месяц раньше.
Юра учился в БГУ на радиофизике и компьютерных технологиях. Во время универа работал на стройке: держал обои, красил стены и получал по 30 долларов в день. Учебу решил бросить в пользу этих невероятно шальных денег и стал работать «официальным» подсобником. После двух кризисов строительных работ, когда вся бригада сидела и не делала приблизительно ничего, прислушался к знакомым, которые говорили бросать, и ушел со стройки. У нас тогда работала его бывшая одногруппница. Она предложила Юре попробовать пойти на вакансию менеджера и дала рекомендации по подготовке. Он прошел самый базовый курс по HTML, почитал про разработку сайтов. В Nineseven у Юры было первое и единственное собеседование в жизни.
Паша закончил военную академию, какое-то время поработал и ушел со службы. После армии пошел в классийский офлайн-бизнес — грузоперевозки, но надолго там задерживаться не стал. Жена Паши работала в IT работает, у него вроде всегда душа лежала к этому. Посмотрел какие-то курсы по программированию — не понравилось. Решил пойти на курсы для менеджеров. Прошел два курса и начал искать работу — натолкнулся на вакансию продажника в Nineseven, прошел собеседование и устроился на испытательный срок.
Про выживаемость набранных менеджеров сложно сказать. Изначально набрали 5-6 менеджеров, из них кроме Паши и Юры никого сейчас не осталось, уходили по разным причинам.
Один человек уволился и пошел работать дальнобойщиком. Почему? Кто его знает. Другой играл в покер, выиграл что-то в районе 150 000 долларов, открыл свой бар и сейчас им управляет. Девчонка была бывшая программистка, поработала у нас какое-то время и сказала «не, ну его» и ушла.
Наверное, меня этот вопрос еще ждет впереди, если будут новые проекты. Но, скорее всего, мы будем медленно расти в плане менеджеров. У нас 2-3 сделки в год — это как бы хорошо, а менеджер может вести, условно, по пять проектов.
Мы сейчас загружены, и мне чтобы еще одного менеджера взять штат, надо еще 2 года набирать проекты.
Nineseven.ru начала активно расти с 2019 года. Мы увеличили оборот с 312 296 долларов в 2020 году и команды из 10 человек до 862 150 долларов и штата из 33 человек в 2024 году, и в основном это технические специалисты.
Краткая выжимка наших изменений:
Сменили фокус с дизайна на разработку и создание конечного продукта
Сосредоточились на e-commerce проектах
Создали софт для финансового учета
Отменили зарплаты менеджерам и перевели их на процент с прибыли агентства по проектам, которые они ведут
Перевели исполнителей на почасовую оплату
Сформировали четкие критерии отбора менеджеров и организовали поэтапное собеседование с обучением и тестовыми заданиями
Начали обучать менеджеров основам дизайна, верстки и программирования
В 2005 году я увлекся популярным сериалом «Симпсоны». Я смотрел все предыдущие сезоны и пытался поймать каждую новую серию по мере ее выхода. Однако со временем я перестал следить за сериалом. Недавно, выбирая, что посмотреть, мой выбор снова пал на «Симпсонов». Судя по всему создатели не собираются заканчивать, а ведь уже уже 35 сезонов!
Несмотря на долгую историю, «Симпсоны» продолжают смешно шутить и затрагивают интересные темы. В другом не менее известном мультсериале даже придумали мем «Это уже было в Симпсонах», подчеркивая широкий спектр того, о чем они снимали серии.
Это уже было в Симпсонах
Среди многих тем, которые затронули «Симпсоны», —, конечно же, управление продуктом. В этой статье будет рассмотрен одна из серий, в которой можно найти множество типичных ошибок управления продуктами в компаниях. Серия называется «О, брат, где ты?» (Сезона 2, Эпизод 15), которая впервые вышла в эфир в 1991 году (еще до того, как некоторые из вас родились).
В этом эпизоде Гомер обнаруживает своего давно потерянного брата Херба Пауэлла, который является генеральным директором крупной автомобильной компании Powell Motors.
Херб и Гомер
Компания сталкивается с трудностями и нуждается в переменах. План Херба состоит в том, чтобы Гомер спроектировал новую машину, полагая, что Гомер, является типичным представителем целевой аудитории. Херб надеется, что автомобиль, разработанный Гомером, найдет отклик у похожих на него людей по всей Америке.
К сожалению, план не сработал, и полученный продукт полностью провалился.
Давайте рассмотрим основные ошибки управления продуктом.
Гомеру, у которого нет опыта ни в области управления продуктами, ни в автомобильной промышленности, поручили создать новый автомобиль.
И я хочу платить тебе 200 тысяч $
-Знаешь, почему я дал тебе эту работу?
-Потому что ты считаешь меня гением?
-Нет, я не считаю тебя гением.
-Потому что ты думаешь, что я энергичный
- Я не думаю, что ты энергичный
-Потому что ты думаешь, что я хорошо работаю с другими?
-Нет, нет, нет, нет!
-Гомер, я дал тебе эту работу, потому что ты заурядный.
Это правда, что люди с разным профессиональным опытом могут добиться успеха в управлении продуктом. Однако новичкам в этой области в идеале следует начинать с небольших, менее важных проектов. Эта стратегия позволяет минимизировать риски и получить ценный опыт, прежде чем брать на себя более важные обязанности. В данном случае решение Херба привлечь Гомера было продиктовано их семейными связями и желанием применить нетрадиционный подход к спасению компании. К сожалению, это поспешное решение усугубило положение компании.
Несмотря на неудачу Гомера в этом эпизоде, в реальной жизни есть примеры людей, преуспевших в управлении продуктом без предварительного опыта в этой области. Например, Илон Маск произвел революцию в автомобильной промышленности с помощью Tesla, несмотря на то, что у него нет традиционного автомобильного опыта. Однако, в отличие от Гомера, Маск уже имел успешный опыт работы в мире бизнеса, в первую очередь с PayPal. Опыт Гомера же включал в себя работу инспектором по безопасности на АЭС Спрингфилд, что не дало ему необходимых навыков или опыта для управления продуктами в автомобильной промышленности.
Приход Илона Маска в автомобильную промышленность был подкреплен видением и стремлением к инновациям, , что показывает, что даже новички могут оказать значительное влияние при правильном мышлении, преданности делу и хорошему базису в других близких областях.
Компания Powell Motors столкнулась с серьезными проблемами при анализе рынка и определении потребностей клиентов. На совещании топ-менеджмента обсуждается плохая работа компании, но никто не может точно определить истинные причины кризиса. Даже предположения менеджеров кажутся абсурдными:
-Каждый день мы сдаем позиции японцам, и я хочу знать, почему?
- Недобросовестная торговая практика?
- Идиоты в Вашингтоне?
- Может быть цыганское проклятие?
-Каждый день мы сдаем позиции японцам, и я хочу знать, почему?
Топ-менеджеры также кажутся оторванными от реальности при обсуждении названия новой модели:
- Вы придумали название для нашей новой экономичной модели?
- Вам это понравится, шеф! Персефона!
-Персефона? Что это за название, черт подери?
- Она была греческой богиней весны и возрождения.
Персефона
Когда Гомера назначают на новую должность, Херб проводит крайне поверхностные исследования рынка. В итоге все ресурсы компании направлены на разработку продукта, основанного исключительно на мнении одного покупателя, а само исследование было сделано некорректно:
-Хорошо, тогда я хотел бы большую.
- У нас нет большой.
-Почему нет?
-Американцам не нужны большие машины
-Ну, дайте мне машину помощнее.
- Извините, у нас нет мощных автомобилей.
-Почему нет?
-Потому что американцам нужен хороший пробег, а не мощность.
- Скажи милому человеку, из какой ты страны.
-Америка!
- Слышите, болваны? Вот почему нас убивают на рынке! Вместо того, чтобы послушать, чего хотят люди, вы говорите им, чего они хотят.
Когда команда пытается спросить Гомера о его предпочтениях, это тоже не приводит к четким результатам:
-Итак, какую машину вы бы хотели, мистер Симпсон?
-Я не знаю.
Херб переоценивает роль менеджера по продукту, назначая Гомера единственным арбитром истины, предполагая, что остальные клиенты разделяют все его желания и потребности. Гомер не консультируется с потенциальными клиентами или экспертами и не проверяет свои предположения на практике. В результате команда сосредотачивается на создании автомобиля, который исключительно удовлетворяет видение Гомера об идеальном автомобиле, не принимая во внимание рыночную конкуренцию и тот факт, что у других пользователей могут быть совсем другие предпочтения.
Хотя некоторые лидеры отрасли, такие как Генри Форд, действительно добились успеха, полагаясь на свое видение и интуицию, такие примеры редки и часто включают исключительных людей с глубоким пониманием рынка. Форд сказал,
Если бы я спросил людей, чего они хотят, они бы ответили, что это более быстрые лошади.
Однако для большинства продакт-менеджеров очень важно проводить тщательное исследование рынка и привлекать потенциальных клиентов для выявления их потребностей и предпочтений. Такой подход значительно снижает риск разработки продуктов, не отвечающих требованиям рынка.
Концепция Херба о создании автомобиля для среднего американца была слишком расплывчатой и лишенной конкретики.
-Я хочу, чтобы ты помог мне спроектировать машину. Автомобиль для всех Гомеров Симпсонов.
Компания была сосредоточена на выпуске очень доступных автомобилей. В начале эпизода они заняты выбором имени для бюджетной машины, что становится очевидным, когда Херб предлагает Гомеру выбрать себе машину.
- Знаешь, чего они мне стоили? В них железа на 40 баксов.
В них железа на 40 баксов
Не понимая стратегии и не имея никаких ограничений, Гомер проектирует автомобиль, который даже по сегодняшним меркам кажется довольно дорогим. Цена автомобиля составила 82 тыс. $, несмотря на то, что в то время автомобили для массового рынка стоили от 10 до 15 тыс." class="formula inline">.
- Сколько стоит это чудовище?
-82 тысячи долларов.
Никто не задумывался, сможет ли целевая аудитория, представленная Гомер Симпсонами, позволить себе такую машину.
Известным примером компании, совершившей подобные ошибки, является Segway. Segway PT был помпезно представленпредставлел в 2001 году. Ожидалось, что он произведет революцию в городском транспорте. Однако продукт не оправдал ожиданий прежде всего из-за неясного целевого рынка, высокой цены и ограниченной практичности. Целевая аудитория Segway PT не была четко определена, а его цена около 5000 долларов делала его недоступным для среднего потребителя.
Как и в случае с эпизодом «Симпсоны», эти примеры иллюстрируют важность наличия четкой стратегии и определения целевого рынка в управлении продуктом. Понимание потребностей, предпочтений и финансовых возможностей целевой аудитории имеет решающее значение для разработки продуктов, которые находят отклик у предполагаемых клиентов и добиваются успеха на рынке.
Гомеру дана невероятная власть, о которой многие продакт-менеджеры могут только мечтать:
- Направляйте все свои вопросы мистеру Гомеру Симпсону, человеку с видением. Человек, который поможет этой компании выбраться из ямы. Человек, который навсегда изменит американский транспорт!
Все вопросы направляйте мистеру Гомеру Симпсону.
Команда общается с Гомером, используя технический жаргон, который он не понимает, не пытаясь объяснить свои решения.
- Ставим что-то бортовое и реечный руль...
Изначально команда не доверяет Гомеру и старается не допускать его к процессу принятия решений.
- Мистер Симпсон, ваш брат сказал вам помочь нам с этой машиной, не так ли?
-Да.
-Почему бы вам не принести нам кофе?
Однако генеральный директор снова вмешивается, предоставляя Гомеру неограниченную власть, фактически превращая его в диктатора, который отдает приказы без обсуждения или учета мнения команды.
В общении с командой Гомер выявляет несколько пользовательских проблем, но тут же предлагает решения, не позволяя команде предлагать оптимальные альтернативы. Например, Гомер освещает проблему общения с шумными детьми в машине:
- Иногда дети сидят на заднем сиденье, орут, бесят. Вы наверняка что вы можете сделать с этим?
Однако когда кто-то предлагает решение, не устраивающее Гомера, это приводит к тяжелым последствиям:
-Ты уволен! За что мы ему платим?
Человек с видением
Попытки команды эскалировать на руководство не увенчались успехом:
- Я рад, что ты нервничаешь, потому что это значит, что мы на правильном пути.
Даже несмотря на негативные отзывы от членов команды, генеральный директор отказывается их слушать. В одной из сцен он просит дать отзыв о Гомере, попросив полностью исказить смысл сказанного:
-Гомер Симпсон — блестящий человек с множеством продуманных практических идей. Он обеспечит финансовую безопасность этой компании на долгие годы.
Херб настаивает на том, чтобы ему не показывали новую машину, пока она не будет полностью закончена.
- Этот проект является нашим главным приоритетом. Все остальное на паузу, я не хочу ничего видеть, пока он не будет закончен.
Гомер, конечно же, не знаком с ключевыми понятиями управления продуктом, такими как «MVP» (минимально жизнеспособный продукт) и «итеративный подход». У него нет четкого плана по разработке и внедрению автомобиля, что приводит к таким проблемам, как непоследовательность дизайнерских решений, увеличение затрат и сложности с контролем процесса разработки.
При разработке автомобиля Гомер не просит обратной связи от потенциальных клиентов и не прислушивается к советам экспертов, которые могли бы значительно улучшить продукт. Вместо этого он полагается исключительно на свои собственные идеи и предпочтения.
Когда продукт, наконец, представлен потребителям и экспертам, он вызывает полное недоумение..
Реакция клиентов
Известным примером продукта, допустившим подобную ошибку, является запуск Google Glass в 2013 году. Продукт представлял собой очки со встроенным компьютером, призванный революционизировать то, как люди взаимодействуют с технологиями. Однако Google Glass были запущены без MVP, что привело к высокой цене, проблемам конфиденциальности и отсутствию четких вариантов использования.
Google Glass не получал отзывов от потенциальных клиентов во время разработки, что привело к тому, что продукт не нашел отклика на рынке. Когда он наконец был представлен публике, он был встречен со скепсисом и большим количество негатива, что вынудило Google прекратить выпуск продукта в его первоначальном виде в 2015 году.
Этот пример подчеркивает важность включения MVP, итерационных подходов и обратной связи с клиентами в управление продуктом. Так компании могут избежать дорогостоящих ошибок, улучшить продукты и повысить вероятность успеха на рынке.
Гомер попадает в ловушку, добавляя в автомобиль множество функций, элементов дизайна и функций, не упрощая дизайн и не удаляя ненужные компоненты, что делает продукт в целом трудным для понимания и менее целостным.
Стоит отметить, что некоторые из предложенных Гомером функций действительно отражают его подлинные потребности:
-Мне нужно место в этой машине, чтобы поставить мой напиток… Я сказал поставить МОЙ напиток. Вы знаете Super Slakers, которые продаются в Kwik-e-Marts. Чашка такая БОЛЬШАЯ.
-Знаешь этот маленький мячик, который ты надеваешь на антенну, чтобы найти свою машину на парковке.
Другие предложения сбивают с толку и кажутся излишними:
-Некоторые вещи настолько шикарны, что никогда не выйдут из моды, например, хвостовые стабилизаторы и пузырьковых сводов и пушистых ковров
-Когда я включу двигатель, пусть люди думают, что наступает конец света.
-Я хочу клаксон здесь, здесь и здесь. Ты никогда не сможешь найти свой клаксон, когда злишься. И они должны играть «Ла Кукарачу».
Первое демо продукта
В результате из-за чрезмерного количества функций автомобиль становится слишком дорогим в производстве и не оправдывает ожиданий большинства потенциальных покупателей. Это служит своеобразным предостережением для менеджеров по продуктам, для избежания перегрузки функциями и фокусе на удовлетворении основных потребностей своей целевой аудитории. Простота и удобство использования часто важнее длинного списка функций, которые могут не иметь существенной ценности.
Известный реальный пример продукта, пострадавший от перегруженности функциями, — Juicero. Эта высокотехнологичная соковыжималка была разработан для производства свежевыжатого сока с использованием запатентованных пакетов для сока, и была оснащена избыточными функциями, такими как подключение к Wi-Fi, сканер QR-кода для проверки свежести пакетов для сока и чрезмерно сложной механической системой,. чтобы выжать сок. Дорогой и сложный дизайн сделал ее менее привлекательной для потребителей, которые могли выбрать более простые и доступные альтернативы приготовлению сока. Juicero в конечном итоге потерпел неудачу на рынке из-за своей высокой цены и ненужных функций.
Мы рассмотрели шесть важнейших проблем управления продуктом, с которыми столкнулись Гомер Симпсон и Херб Пауэлл:
Некомпетентность продакт-менеджера
Отсутствие анализа рынка и потребностей клиентов.
Неадекватная стратегия и нечеткое определение целевого рынка.
Плохое взаимодействие с командой и авторитарное управление.
Отсутствие MVP, итеративного подхода и обратной связи
Перегрузка продукта излишними функциями.
Не повторяйте ошибок Гомера Симпсона в своей профессиональной практике. Найдите время, чтобы посмотреть этот выпуск и поразмыслить над опытом своих коллег или даже над своими прошлыми ошибками.
Настоящий Гомер Симпсон ( Шедеврум)
Возможно, этот эпизод поможет вам извлечь ценные уроки и предотвратить подобные ошибки в вашей профессиональной практике.
Помните о важности подготовки, исследования рынка, анализа потребностей клиентов и разработки четкой стратегии с четко определенным целевым рынком. Хорошие коммуникативные навыки с и навыки управления проектами также являются важными факторами успеха.
Используйте принципы MVP и активно используйте обратную связь для более эффективного достижения желаемых результатов без излишней траты ресурсов и времени. Вдумчиво выбирайте функции продукта, исходя из реальных потребностей пользователей, и избегайте перегрузки продукта ненужными функциями, которые могут усложнить его использование и увеличить затраты на разработку и эксплуатацию.
Интересно, что автомобиль, спроектированный Гомером и его командой, позже был воссоздан в реальной жизни, но исключительно для участия в шуточных соревнованиях.
Автомобиль Гомера Симпсона
Он еще раз напоминает о ценных уроках, которые менеджеры по продуктам могут извлечь из этой серии, улучшить свои навыки и избежать подобных ловушек.
p.s. ну и “по классике”, в конце концов генеральный директор обвинил продакта в крахе компании ?
-Прощай Херб, из-за меня ты потерял свое дело, свой дом и все свое имущество. Может быть тебе было лучше, если бы я никогда не появлялся в твоей жизни.
-Может быть мне было лучше??? Может быть??? Кретин, конечно мне было бы лучше! Прошу запомнить, что у меня больше нет брата!
p.p.s. Если вы дочитали до конца, то вам наверняка понравится мой тг-канал Inspired Product Manager, где я ищу нестандартные способы донесения информации?, разбавляю своим опытом и яркими примерами!
Подписывайтесь!
