Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Спасибо за статью!!!
Вы писали:
>>> Что касается разработки техзадания и заключения договоров — это типичные такие менеджеры, которые работают по проектному принципу с задачей «договориться с заказчиком, выдать задачи исполнителям, и следить чтобы всё было по графику». Директор наверняка будет с нетерпением ждать этих орлов в кабинете каждый отчётный период и ни за что не делегирует возможность дать им разгон своему заму.
Можно немного поподробнее?
Вы писали:
>>> Что касается разработки техзадания и заключения договоров — это типичные такие менеджеры, которые работают по проектному принципу с задачей «договориться с заказчиком, выдать задачи исполнителям, и следить чтобы всё было по графику». Директор наверняка будет с нетерпением ждать этих орлов в кабинете каждый отчётный период и ни за что не делегирует возможность дать им разгон своему заму.
Можно немного поподробнее?
Не за что, рад что понравилось :-)
Имеется в виду, что отчитываются товарищи менеджеры проектов непосредственно перед директором, т.к. от них зависит доход организации.
На самом деле, это должен быть не директор, а руководитель проектного офиса, который в содружестве с финотделом строят бюджет доходов и расходов (исходя из актирования и зарплат исполнителей). А директор должен вмешиваться только если какой-то проект пошёл ну совсем не туда.
Имеется в виду, что отчитываются товарищи менеджеры проектов непосредственно перед директором, т.к. от них зависит доход организации.
На самом деле, это должен быть не директор, а руководитель проектного офиса, который в содружестве с финотделом строят бюджет доходов и расходов (исходя из актирования и зарплат исполнителей). А директор должен вмешиваться только если какой-то проект пошёл ну совсем не туда.
Сейчас наверняка придут намного более опытные в сфере организации IT производства граждане, а я лишь отмечу что вы не отразили на своей схеме главный вывод статьи, а именно: сопровождение это 2/3 и больше от всего цикла разработки продукта.
Как я понимаю, речь идет об очень большой компании, создающей очень сложное ПО? Просто для простых проектов слишком много отделов, они будут мешать друг другу.
Да, изначально мысль была не про мелкий бизнес )
Тему разговора в тот раз поднял не я, но теоретизирование «на тему» оказалось настолько любопытным, что я не выдержал и написал этот текст :-)
Тему разговора в тот раз поднял не я, но теоретизирование «на тему» оказалось настолько любопытным, что я не выдержал и написал этот текст :-)
Для большой компании ваша схема плохо подходит. Как минимум сразу видны места, где из-за бюрократии дела будут пробуксовывать:
— взаимодествие Иб с админами и разработчиками
— взаимодействие между админами и разработчиками
— взаимодействие между разработчиками и тестировщиками
— взаимодействие между code monkeys и архитекторами.
Плюс куча искусственных разделений. Например, на программистов, алгоритмистов и проектировщиков (зачем разделять две последние группы, совершенно непонятно), или на DBA и остальных админов. Причем так, что связаны они только через гендиректора. Малейший конфликт и ему придется самому разруливать, всяку ерунду, вроде того, какие индексы надо создавать.
Вообще, в нормальной ситуации тестировщики, разработчики и админы одного проекта работают в одной команде.
— взаимодествие Иб с админами и разработчиками
— взаимодействие между админами и разработчиками
— взаимодействие между разработчиками и тестировщиками
— взаимодействие между code monkeys и архитекторами.
Плюс куча искусственных разделений. Например, на программистов, алгоритмистов и проектировщиков (зачем разделять две последние группы, совершенно непонятно), или на DBA и остальных админов. Причем так, что связаны они только через гендиректора. Малейший конфликт и ему придется самому разруливать, всяку ерунду, вроде того, какие индексы надо создавать.
Вообще, в нормальной ситуации тестировщики, разработчики и админы одного проекта работают в одной команде.
Я бы отдел математического обеспечения не ставил бы в подразделения развития. Это методологи, обычный бек-офис, в данном случае операционной деятельности.
Отдел проектирования ПО, аналогично, судя по описанию, это core-команда разработчиков, место ей в разработке ПО.
А кто же тогда в развитии? Продуктологи, маркетологи и родственники директоров.
Отдел проектирования ПО, аналогично, судя по описанию, это core-команда разработчиков, место ей в разработке ПО.
А кто же тогда в развитии? Продуктологи, маркетологи и родственники директоров.
Современные представления об управлении фокусируются на процессах, а не на отделах. Оргструктура производства при этом может вообще не быть иерархичной.
Отдел прикладного, отдел веб, отдел бд…
У вас матричная структура производства? Почему на ней остановились, а не на проектной?
В 95% случаях один и тот же разработчик может писать и прикладное, и веб, и для бд. И получаться будет значительно эффективнее в плане уменьшения количества коммуникаций (между максимум 3 девов и менеджера, который обязан выжечь в камне апи между слоями).
В остальных 5% случаев достаточно пригласить на «пару часиков» гуру дизайна, оракла и т.п., чтобы решить исключительные задачи.
Департамент развития считаю антипаттерном.
Архитектуру очень опасно вырывать из производства, потому что даже она может меняться со временем. Особенно актуально при решении неопределенных задач а-ля стартап или когда заказчик вообще не знает, что ему надо и/или когда процессы быстро меняются.
Или например, под невстречающуюся ранее задачу выбрали некий инструмент, который оказался багованный/неудобный в использовании. Если держать руку на пульсе, можно успеть его сменить более удобным.
Или такой вариант — вливается новая кровь в команду. Этот человек может рассказать о своем опыте, новых более удобных инструментах разработки и т.п.
Но если такие вопросы решает некий отдел, их решение может затянуться и в итоге народ просто не будет проявлять инициативу по улучшениям, стек технологий будет устаревать. Значит, текущий код может стать тяжело поддерживаемым, можете потерять возможность быть на волне как более производительных инструментов, так и нанимать лучших и отличных спецов, потому что ваши устаревшие технологии никого не привлекают.
Почему? Неужели так плохо написано?
P.S. Вообще можете не париться, сейчас даже с ужасными процессами и устаревшими технологиями, толпой студентов на позициях лидов компании работают, развиваются и зарабатывают деньги.
У вас матричная структура производства? Почему на ней остановились, а не на проектной?
В 95% случаях один и тот же разработчик может писать и прикладное, и веб, и для бд. И получаться будет значительно эффективнее в плане уменьшения количества коммуникаций (между максимум 3 девов и менеджера, который обязан выжечь в камне апи между слоями).
В остальных 5% случаев достаточно пригласить на «пару часиков» гуру дизайна, оракла и т.п., чтобы решить исключительные задачи.
Департамент развития считаю антипаттерном.
Архитектуру очень опасно вырывать из производства, потому что даже она может меняться со временем. Особенно актуально при решении неопределенных задач а-ля стартап или когда заказчик вообще не знает, что ему надо и/или когда процессы быстро меняются.
Или например, под невстречающуюся ранее задачу выбрали некий инструмент, который оказался багованный/неудобный в использовании. Если держать руку на пульсе, можно успеть его сменить более удобным.
Или такой вариант — вливается новая кровь в команду. Этот человек может рассказать о своем опыте, новых более удобных инструментах разработки и т.п.
Но если такие вопросы решает некий отдел, их решение может затянуться и в итоге народ просто не будет проявлять инициативу по улучшениям, стек технологий будет устаревать. Значит, текущий код может стать тяжело поддерживаемым, можете потерять возможность быть на волне как более производительных инструментов, так и нанимать лучших и отличных спецов, потому что ваши устаревшие технологии никого не привлекают.
Передать такое на поддержку куда бы то ни было принципиально невозможно.
Почему? Неужели так плохо написано?
P.S. Вообще можете не париться, сейчас даже с ужасными процессами и устаревшими технологиями, толпой студентов на позициях лидов компании работают, развиваются и зарабатывают деньги.
Спасибо за мнение!
По вопросу как написано — ну не так замечательно, как хотелось бы, но работает, что самое характерное. Значит, не так и плохо :-)
А по поводу «зарабатывают деньги» — так я и не парюсь, так-то… Мне мнения интересны.
По вопросу как написано — ну не так замечательно, как хотелось бы, но работает, что самое характерное. Значит, не так и плохо :-)
А по поводу «зарабатывают деньги» — так я и не парюсь, так-то… Мне мнения интересны.
Над продуктом должна работать команда. Все, и разработчики, и DBA, и QA, и архитекторы.
А так получается" «я свою часть работы сделал, а дальше не моя забота».
Или еще хуже: «Что, мой идеально обточенный квадратный люк не подходит к вашему круглому отверстию? Ну так вот же в ТЗ написано, что люк должен быть квадратным. Не надо рассказывать мне про логику, в ТЗ так напиано! Идите в отдел проектирования, пусть исправят ТЗ.» В отделе проектирования: «Мы не уверены, что круглые люки возможны, возможно вам подойдет овальный? Уточните в отделе математического обеспечения.»… Спустя год, круглые люки все-таки появились. И тут взвыл отдел сопровождения: их то не предупредили, что теперь придется поддерживать два типа люков.
А так получается" «я свою часть работы сделал, а дальше не моя забота».
Или еще хуже: «Что, мой идеально обточенный квадратный люк не подходит к вашему круглому отверстию? Ну так вот же в ТЗ написано, что люк должен быть квадратным. Не надо рассказывать мне про логику, в ТЗ так напиано! Идите в отдел проектирования, пусть исправят ТЗ.» В отделе проектирования: «Мы не уверены, что круглые люки возможны, возможно вам подойдет овальный? Уточните в отделе математического обеспечения.»… Спустя год, круглые люки все-таки появились. И тут взвыл отдел сопровождения: их то не предупредили, что теперь придется поддерживать два типа люков.
Над продуктом должна работать команда. Все, и разработчики, и DBA, и QA, и архитекторы.
Такого слона уже не продать. Продукт — это то, что снаружи надо потенциальным покупателям, а не то, как себе это представляют специалисты в других областях.
> И тут взвыл отдел сопровождения: их то не предупредили, что теперь придется поддерживать два типа люков.
Ха-ха! У вас просто мало опыта =)
В таких случаях создается ПАТЧ, делающий из квадратного люка — круглый. Ну, точнее, почти круглый. Пара ударов кувалдой — и люк как тут и был! Ах, вы хотели иногда этот люк открывать?..
Ну и так далее. =)
Ха-ха! У вас просто мало опыта =)
В таких случаях создается ПАТЧ, делающий из квадратного люка — круглый. Ну, точнее, почти круглый. Пара ударов кувалдой — и люк как тут и был! Ах, вы хотели иногда этот люк открывать?..
Ну и так далее. =)
Ожидал увидеть эту картинку в комментариях
Ваша схема хорошо подходит вырожденной организации численностью 60-80 человек, у которой всегда есть работа (госзаказ, субподрядчик под другую крупную контору). В реалиях обязательно надо добавлять продавцов и маркетологов — откуда же вы обеспечите приток заказов без них? А их же тоже надо делить на подотделы (массовый рынок, средний и малый бизнес, развитие бизнеса, рекламщики). А еще нет бухгалтеров, юристов, специалистов по работе с контрагентами, логистов и прочего офисного планктона. К сожалению в вашей оргструктуре не на кого переложить этот функционал. Кроме того, после реализованных 2-3х десятков проектов потребуется некоторый аналог колл-центра.
Вы очень точно попали — именно такой эдем и рисовался, то есть без продавцов и маркетологов. Бухгалтеров и юристов я сознательно вынес за скобки, так как в процессе разработки ПО они участвуют постольку поскольку, если, конечно, не являются заказчиками :-)
А вот про колл-центр вы правы. Он однозначно живёт где-то в операционной деятельности, и я про него доблестно забыл в момент написания этого текста.
А вот про колл-центр вы правы. Он однозначно живёт где-то в операционной деятельности, и я про него доблестно забыл в момент написания этого текста.
Обычно крупные конторы не просто занимаются прогерством, а еще и некоторой интеграцией. Чистое программирование удел контор, пишущих варез (продукт на массового пользователя) или контор, обслуживающих на постоянной основе несколько сервисов. А если есть интеграция, нужна еще и логистика и складской учет, инсталяторы, специалисты по субподрядчикам.
А зачем для интеграции софта типа ERP/MES логистика? (я наверное чего-то не понимаю)
Но вы же предоставляете полный спектр услуг? То есть скорее всего вам потребуется закупка, доставка и монтаж платформы, на которой будут крутиться ваши сервисы у заказчиков. Если конечно у вас будет не один заказчик.
А еще возможно сетевое оборудование. Кроме того, кто-то же должен заниматься доставкой стульев и техники для ваших сотрудников?
А еще возможно сетевое оборудование. Кроме того, кто-то же должен заниматься доставкой стульев и техники для ваших сотрудников?
По схеме 2 хотелось бы отметить:
«Концептуальное ТЗ» от проектного офиса обычно оставляет желать лучшего. Поэтому критически важен «Системный анализ» после проектного офиса и до «Архитектуры». Т.е. в вашей схеме упущен целый пласт работ: например, модель предметной области, что приведет к повторным разработкам одного и того же, неэффективным решениям и т.д. В реальной жизни системные аналитики кроме своей работы, еще до ума БТЗ от проектного офиса доводят.
И непонятно, какие работы будут выполнены в пункте «Создание технической документации». Что они пишут, пользовательскую документацию? Если так, то эта работа должна быть параллельно с реализацией.
«Концептуальное ТЗ» от проектного офиса обычно оставляет желать лучшего. Поэтому критически важен «Системный анализ» после проектного офиса и до «Архитектуры». Т.е. в вашей схеме упущен целый пласт работ: например, модель предметной области, что приведет к повторным разработкам одного и того же, неэффективным решениям и т.д. В реальной жизни системные аналитики кроме своей работы, еще до ума БТЗ от проектного офиса доводят.
И непонятно, какие работы будут выполнены в пункте «Создание технической документации». Что они пишут, пользовательскую документацию? Если так, то эта работа должна быть параллельно с реализацией.
Согласен, тоже бросилось в глаза. Как тех. документация до ПО появляется, а не параллельно, это раз, во вторых это верхнему топу (по операциям) прерывает цепочку. Если сдвинуть хотя бы за реализацию этот квадратик, становится и понятнее и логичнее.
Казалось бы прерывает и «ну и чо». А вот нет. Если так печь пироги, то за его сфера ответственности не целостна, если на основе тех. документации разработчики хоть что-либо делают, и это весьма чревато несоответствиями с тем что хотели документаторы, сделали разработчики, и что внедрили и поддерживают внедренцы. Если разработчики не делают ничего на основе той самой тех. документации, то квадраты лучше поменять местами.
Казалось бы прерывает и «ну и чо». А вот нет. Если так печь пироги, то за его сфера ответственности не целостна, если на основе тех. документации разработчики хоть что-либо делают, и это весьма чревато несоответствиями с тем что хотели документаторы, сделали разработчики, и что внедрили и поддерживают внедренцы. Если разработчики не делают ничего на основе той самой тех. документации, то квадраты лучше поменять местами.
Набрёл на статью по поиску в гугле. Пишу, скорее, для менеджеров, которые тоже нашли эту статью, чем автору. Нельзя совмещать сопровождение и развитие, это должны быть разные люди. Если вы заставляете инженера сопровождения заниматься внедрением какой-то новой системы или даёте ему поручения не связанные с сопровождением, да ещё и сроки сжатые, как это обычно бывает, то под вашим давлением он забьёт на старые системы и это приведёт к аварийной ситуации. А если он ещё и не проследит за бэкапами и прочей работой, которую не видят менеджеры, закончившие двухнедельные курсы по управлению и не имеющие реального опыта сопровождения, то это это будет полный провал в управлении.
Спасибо за ответ, даже не ожидал, что спустя шесть лет кто-то эту статью ещё читает )
Насколько я помню идею этой статьи — разговор как раз об том, чтобы эти две должности были на разных людях. Иначе тот, кто будет пытаться усидеть на двух стульях, или заработает шизофрению, или профакапит одну из своих ролей.
Насколько я помню идею этой статьи — разговор как раз об том, чтобы эти две должности были на разных людях. Иначе тот, кто будет пытаться усидеть на двух стульях, или заработает шизофрению, или профакапит одну из своих ролей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Об оргструктуре и бюрократии