Давно хотел написать о том, как по моему мнению должна быть построена иерархия в компания.
Но, как точно заметил СОТОНА, на идеальный пост времени нету.
Так что буду потихоньку эту тему раскапывать.
В общем ситуация следующая. Неправильная иерархия для компания, делает тоже самое что неправильная архитектура для программы. То есть при неправильной иерархии вроде и все работать
может, но сбоит по черному и непонятно откуда у проблем растут ноги.
Итак, сначала покажу схемку, которую я набросал пару месяцев назад. Сразу скажу, что могут быть какие-то огрехи, но главное я хотел передать идею….
Итак, вот она схемка. Схемка того, как должна выглядеть продуктовая контора или продуктова/сервисная. Впрочем даже сильно сервисная может так тоже выглядеть, но с небольшими модификациями.
А теперь, о том, что я имел ею в виду
— Первое и самое основное (того, чего в схемке не указано). У каждой позиции должен быть четкий список обязанностей и ответственности. Директор по продажам не должен садиться подпедалить код,
а технический менеджер не должен мотаться по всему миру собирая у заказчиков требования.
Я кстати об этом писал в статье «О разделении обязанностей между технарями и продавцами.»
— Второе. Это размер фирмы. Естественно, нарисованная фирма скорее выглядит как что-то эдак размером человек 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 — краткосрочное планирование (вся тактика). Соответственно, гораздо больше завязанное на то, что нужно с продуктом сделать прямо сейчас.
[…] меня была статья в которой я уже начал описывать структуру компании, […]
Считаю не совсем правильным ставить QA в подчинение к PMу.
В этом случае рискуем за счёт власти, которой обладает PM, получить обрезанную проверку продукта. Конечно одна из задач PMa — выпуск качественного продукта. Но на практике PM с большей охотой поступится тестированием продукта чем сроками сдачи или риском превысить бюджет.
Этому способствует и то, что тестирование (чаще всего) выполняется на последних стадиях проекта. Т.е. когда приходит осознание уже и жертвовать больше нечем.
Целесообразно держать QA в стороне. Да, PM даёт туда задачи. А QA защищает свою сторону. И в случае необходимсти не пропускает продукт наружу.
QA должен иметь достаточно полномочий и возможность эскалации (напрямую, а не через голову своего начальника).
Как я понимаю, основная мысль состоит в том, что QA должно иметь достаточно большое количество полномочий. И я с этим согласен.
Однако, как QA не выделяй, в конце концов кто-то будет стоять выше чем QA, будь это PM, Director Engineering’а, VP или CEO. И в конечном итоге этот человек может пожертвовать качеством продукта относительно сроков сдачи и риском превышения бюджета.
Далее… Описанна ситуация
«с большей охотой поступится тестированием продукта»
«тестирование выполняется на последних стадиях проекта.»
«QA должен иметь достаточно полномочий»
То есть описан, злобный PM, который вопервых выбрал тестирование в самом конце, что уже откровенная редкость, даже для не agile проектов. Во вторых, он самолично (ни с кем не советуясь) решил что сроки важнее и в третьих забил н тестирование…
М… Как бы так сказать, что-то вероятно не ладно в королевстве датском, если в фирме есть такой PM. И как я уже писал, если любой другой человек будет управлять QA и будет настолько же неадекватен — то он сможет загадить проект.
Я считаю, что PM — как раз лицо которое должно отвечать за проект целиком. С одной стороны он принимает решения (советуясь), с другой стороны получает по голове за принятые решения. Иначе получится, что за проект отвечает PM, но в случае каких-то проблем, он махнет в сторону QA и скажем — это все те ребята, я им задачу дал, а они
из сроков вылезли и вообще не соглашаются пропустить продукт в котором 3 ошибки.
Я знаю, что моя позиция состоит в сосредоточии полномочий, но с другой стороны она состоит в сосредоточении ответственностей. Сейчас в большинстве фирм и то и другое
размазанно по фирме и в результате не фига не понятно, кто действительно работает
хорошо и принимает правильные решения, а кто работает плохо.
У тебя картинка под линком «Company structure» здесь пишет «404 Not found». 🙁
О, спасибо. Меня когда хакнули, я убил всю дирректорию upload, так как там были левые скрипты, и случайно убил эту картинку.