Компанейская архитектура.
Давно хотел написать о том, как по моему мнению должна быть построена иерархия в компания.
Но, как точно заметил СОТОНА, на идеальный пост времени нету.
Так что буду потихоньку эту тему раскапывать.
В общем ситуация следующая. Неправильная иерархия для компания, делает тоже самое что неправильная архитектура для программы. То есть при неправильной иерархии вроде и все работать
может, но сбоит по черному и непонятно откуда у проблем растут ноги.
Итак, сначала покажу схемку, которую я набросал пару месяцев назад. Сразу скажу, что могут быть какие-то огрехи, но главное я хотел передать идею….
Итак, вот она схемка. Схемка того, как должна выглядеть продуктовая контора или продуктова/сервисная. Впрочем даже сильно сервисная может так тоже выглядеть, но с небольшими модификациями.
А теперь, о том, что я имел ею в виду
- Первое и самое основное (того, чего в схемке не указано). У каждой позиции должен быть четкий список обязанностей и ответственности. Директор по продажам не должен садиться подпедалить код,
а технический менеджер не должен мотаться по всему миру собирая у заказчиков требования.
Я кстати об этом писал в статье “О разделении обязанностей между технарями и продавцами.”
- Второе. Это размер фирмы. Естественно, нарисованная фирма скорее выглядит как что-то эдак размером человек 500. Скажем так, многие из этих должностей могут быть объедененны в одном человек для небольшой фирмы. Главное, что можно объеденять должности внутри одного подразделения, но не между ними.
То есть может быть и программист и главный программист в одном лице. И product manager с business director’ом в одном лице. Но уж никак не главный QA и sales director в одном флаконе.
Теперь можно уже и по структуре. Основное, с чего я вообще начал рисовать эту схему с Product Manager’а. Звучит конечно смешно, но это самый главный человек в компании. C одной стороны он находится достаточно низко в структуре, чтобы влиять на детали, с другой стороны достаточно высоко, чтобы выбирать направление. В этому его уникальность и ценность одновременно.
Итак, самая основная его идея в том, чтобы собирать все хотелки сверху (от CEO, от Sales (это скорее сбоку)), идеи о том куда двигаться в будущем (от маркетинка), крики и плевки от заказчиков (через отдел support’а) и пинки от engineering’а. После того, как все собрано - все приоритезируется и выдается вниз engineering’у на исполнение и вверх отчетность о приоритетах.
Замечу, дальше в зависимости от удачности или не удачности приоритезации именно product manager’ов (включая business development director) должны либо гладить по голове, либо гладить утюгом.
То есть к ним идут все ниточки входных сигналов и от них идут все ниточки выходных сигналов. Еще раз замечу, не к CEO, а к ним.
Теперь, расходимся от них концентрическими кругами.
В случае если product manager’ов несколько - то Business Director как раз должен руководить, тем чтобы ниточки по нужным направлениями шли к нужному product manager’у и в ответ выходили нужные ответные сигналы.
Кстати, замечу, что если входные сигналы имеют право быть аналоговыми (то есть в достаточно произвольной форме), то выходные сигналы - все должны быть очень цифровым (четкий формат в виде документа с требованиями для инженеров, документа с планом и сроками для sales и т.п.)
Движемся дальше. Когда сигнал опускается до director’а engineering’а - то он обычно заключается в крупных проектах и это уже его дело разбить это напроекты поменьше, раздать менеджерам проектов х контролировать и т.п. В общем-то director engineering’а и project manager’ы это как раз те самые менеджеры среднего звена о которых я писал уже несколько раз.
Дальше движемся вверх по схеме. CEO по большему счету должен быть нужен в фирме для трех вещей
а) В случае наличия инвесторов - общение с ними
б) В случае если он основатель и задумщик идеи - он должен кормить этими идеям product manager’а. Хотя в идеале, тогда он должны перейти на должность Business Development Director и отдать руль CEO кому-то другому.
в) В случае если какая-то ветка работает плохо, разобраться в причине и уволить ее.
Ну и плюс сюда можно приписать воодушивительные выступления перед фирмой.
По большему счету это все, за что он должен отвечать
To be continued…
P.S. Круто… Первая картинка в блоге 
Я считаю, что схема великолепна! Более того, она просто идеальна, совершенна! Одно из самых ярких моих впечатлений от творчества на тему организации бизнеса за последнее время.
Хочется пройтись с комментариями по каждой ветке, захлебываясь от восторга… Но к чему? И так все просто замечательно.
Если честно, то я не пойму - то ли сарказм, то ли у меня появились фаны
Какой может быть сарказм?! Конечно, фаны. Я вот многим своим знакомым ссылку отправил - они тоже в абсолютном восторге!
ok. Спасибо
Как-то просто привычка выработалась не верить в восторг… Такой, я бы сказал, легкий мизантропизм.
Напрасно, совершенно напрасно!
Нужно ценить себя и свои гениальные мысли.
OMG! в этом месте уже и я начал подозревать издёвку
Господь с Вами!
Чем вызваны такие подозрения? Оценка-то вполне объективная.
Практически все комментарии это подтверждают.
Я ценю
>>P.S. Круто… Первая картинка в блоге
Поздравляю Вас, Виктор, опыт удачный
Жаль только, что этой идеально схеме не суждено воплотиться и зарулить кучу продуктофф
Ну почему же? Я верю, что рано или поздно до всех, наконец, дойдет, что эта схема обеспечивает несомненное конкурентное преимущество компании, где она реализована.
По сравнению с какой схемой? По сравнению с отсутствующей организацией - да. А если организация есть, но она другая? Зря вы так, категорично. Всё познаётся в сравнении.
Да и не забывайте учитывать человеческий фактор.
Я, как менеджер, стараюсь строить схемы исходя из тех людей, с которыми я работаю, а не сначала построить схему, а потом каждого впихивать в неё.
Для маленькой компании - сначала должны быть люди, а потом схема.
Для крупной, сначала схема - потом люди.
Да, собственно говоря схема не претендует на то, чтобы быть идеальной. Просто мое видинье мира.
Обычно, крупные компании получаются путём эволюции из мелких.
Схема должна быть в любом случае. В случае маленькой компании она может быть в голове, по мере расширения - развивается и схема и в определённый момент - документируется.
Согласен. Это наиболее правильное описание.
А почему не суждено? Все еще может быть
Ну почему же не суждено воплотиться? В компании где я работаю как раз такая схема.
5 балофф
“Главное, что можно объеденять должности внутри одного подразделения, но не между ними.”
это Вы правильно подметили, если этот принцип нарушается, то всё катится в неизвестно куда. На схеме в основном указано вертикальное взаимодействие, интересно было бы прочитать о горизонтальном взаимодействии м/ду отделами (business unit) .
Собственно горизонтальное взаимодействие я хочу чуть дальше описать.
Особенно оно актуально для support’а, который слегка кросс отделовый.
А как же диалектическое противостояние QA и Project Manager? Вы думаете, что у руководителя проекта достаточно знаний, опыта и времени, чтобы развивать не просто тестирование (этим действительно могут заняться QA Lead’ы), а сам процесс обеспечения качества?
Например, заняться анализом процессов формирования требований, разработки и тестирования с целью пресечь определённый вид “проблем” во всех проектах. Не хватит у подчинённого руководителю проекта QA Lead’у знаний общей картины и полномочий на принятие решений, чтобы изменить что-то.
Наверно вы всё-таки имели в виду Testers, а не QA.
Тем более, что QA отделённое от Support - тоже не выглядит хорошей идеей.
да
в этом блоге исторически сложилось так, что тестировщиков обзывают QA
Похоже уже, действительно исторически сложилось.
Не знаю, у меня просто как-то это застряло в голове, так как в конторах 4 где работал тестировщик = QA engineer, не о каком процессе обеспечения качества (включая качество процессов - речи и не шло, там где я работал (включая мою фирму).
а ещё мне понравилось “sales engineer”
особенно в свете противопоставления технари-маркетинг…
Кстати, в США sales engineering - это вполне типичная роль
Это те, кто работают в sales отдели, но технически подкованны. Чаще всего их засылают вторым эшалоном после того, как sales протолкнули уже идею. Они вполне могут поехать и общаться с технарями и объяснять как все работает.
В общем - это те у кого и язык подвешен и технари. Очень полезная категория, для того, чтобы не дергать основную техническую команду к заказчикам.
Буду похоже потихоньку обновлять и дорисовывать схему.
Имелись в виду таки Testers.
QA, как отдел занимающийся улучшением процессов, будет находится у business development director’а в подчиненнии.
В Support действительно должны быть Tester’ы.
Типичная схем для софтовой компании, что тут такого крутого?
Да. В схеме нету ничего супер невероятного. Только почему-то дай бог 30% контор имею вообще разумную схему взаимодействия.
Даже те кто гордятся своей “правильность” построения фирмы, на поверку оказывается что все у них смешано в кучу и схема только подразумевается.
да ничего такого, картинок мало, цитат из НАтали нет ваще
а в чем отличие функций лежащих на strategic development director и business development director?
как по мне их неплохо слить в одно.
или может быть SDD это Sales director?
а BDD это Production director?
М… Я сказал бы это слегка разные вещи.
Business Development Director - занимается тактикой. То есть тем, что влияет на сегодня (максимум на завтра). Возможно название выбрано не самое правильное.
Stategic Development Director - скорее с помощью маркетинга и головы, пытается анализировать куда двигать в дальносрочной перспективе.
Причем если Business Development Drector выдает распоряжение, что и как делать. То Strategic Director скорее выдает советы - куда двигаться.
ну тогда Strategic Director должен совмещаться с CEO
обычно же CEO является стратегическим движком, или нет?
Да пожалуй можно было бы совместить. Но тогда, вместо него нужно Director Marketing. (не на прямую же им CEO - отвечать). Как по мне Director Marketing - существо достаточно странное. Все же лучше Strategic директор, он все таки отвечает не просто за иследование рынка (что всего лишь часть стратегического планирования), но и за стратегическое развитие в целом.
Виктор, к вашей схеме я бы слёту добавила еще несколько достаточных важных блоков, таких как PMO (Portfolio Management Office), CE (Customer experience team), CC (Customer Care team). Говорю с позиции того самого продакт менеджера в “продуктовой конторе”
И еще, не могли бы вы объяснить что вы вкладываете в понятия “Strategic development director” и “Business development director” и какую разницу видете между этими двумя ролями?
ok. А чуть больше деталей по поводу чем они должны заниматься PMO, CE и CC?
Насчет strategic development - по большему счету человек который занимается долгосрочным планированием. Все то, чему не суждено сбыться ну, скажем в ближайшие пару лет так точно.
Business development director - краткосрочное планирование (вся тактика). Соответственно, гораздо больше завязанное на то, что нужно с продуктом сделать прямо сейчас.