Здравствуй, хабрасообщество.
Не так давно [около года — именно столько времени пролежала статья «в столе»] сидели мы с товарищем и думали за вопросы организации ИТ-компании. В реально большой ИТ-шной компании мы не работали, вся жизнь прошла в ИТ-подразделениях организаций, для которых ИТ — не основной вид бизнеса. Так что, хотя об организационной структуре мы представление имеем, с деталями её применения к приличных размеров конторе, чья жизнь — реализация и сопровождение софта, мы не знакомы.
Получилась после двух часов раздумий у нас примерно такая картинка, основные положения которой поясняются под катом.
Итак, у нас есть организация, которая ведёт достаточно крупные ИТ-проекты, внедряет их по стране, и много времени тратит на их поддержку. Также, из вводных, предполагаем, что бухгалтерия отдаётся на аутсорс.
Тут также имеет смысл упомянуть, что специфика в поддержке больших баз данных и систем обработки этих данных — есть уже несколько работающих решений, которые надо поддерживать.
Для начала распишем, что должна делать организация.
Каждый пункт это, фактически, отдел, хотя некоторые имеет смысл сложить вместе. Например, выпускное тестирование имеет смысл объединить с техдокументацией, а внедрение — с сопровождением.
Такому объединению есть несколько причин:
Для такой схемы есть ещё одна причина, которая будет рассмотрена ниже.
С разработкой всё проще, есть отдел разработки системного и прикладного ПО, отдел веб-технологий, и выделен (так как большой объём работы с БД) отдел работы с БД.
Что касается разработки техзадания и заключения договоров — это типичные такие менеджеры, которые работают по проектному принципу с задачей «договориться с заказчиком, выдать задачи исполнителям, и следить чтобы всё было по графику». Директор наверняка будет с нетерпением ждать этих орлов в кабинете каждый отчётный период и ни за что не делегирует возможность дать им разгон своему заму.
Есть ещё пара пунктов, с которыми не совсем понятно. Это проработка математического обеспечения и разработка архитектуры софта.
Задача отдела матобеспечения — сформулировать методики, написать формулы, проработать методологию бизнес-процессов у заказчика. Этакий пул экспертов, досконально разбирающийся в теме, готовый дать решение по любому концептуальному вопросу.
Отдел проектирования ПО же, скорее, должен заниматься проработкой концептуальной целостности продукта, давать для отдела разработки скелет, который необходимо обтянуть мясом. Как проектный офис — место, где сидят менеджеры, так и отдел проектирования ПО — место, где сидят тимлиды.
Обе задачи не относятся ни к производственной, ни к операционной деятельности. Скорее, это некие отделы НИР, которые смотрят вперёд, собирают оптимальные решения, применяют их на практике и руководят разработкой.
Таким образом, получаем три ветки — развитие, разработка и техподдержка. Каждый проект проходит стадию инициации в проектном офисе, концептуальной проработки в департаменте развития, написания техдокументации в операционном департаменте, разработки, и затем передаётся опять в департамент сопровождения для внедрения.
Такой путь проекта теоретически должен позволить выявить концептуальные недостатки и фактические ошибки внутри организации, не вынося их к заказчику.
Тут требуется сделать небольшое лирическое отступление.
В 2007м году поступило совершенно неформализованное задание «сделать им хорошо». После выяснения, кому именно и как именно надо «сделать хорошо», родился здоровый документ, в котором было всё это написано. Путь согласования документа, прямо скажем, был тернист и извилист, и учитывал интересы всех. Сейчас я понимаю, что, если это всё написать, получилась бы если не 1С, то что-то похожее; тогда мне это было совершенно неочевидно. «Ладно, — подумал я, — фигня, где наша не пропадала!..» — и сел за работу. Месяца через четыре был готов какой-то прототип, и я поехал его сдавать.
Выяснилось, что всё не так: то неудобно, это неверно, тут вообще бизнес-процесс поменялся… ну, в общем, я думаю, все могут представить эту ситуацию. Крякнув, я снова сел за работу.
Через несколько итераций (и после отвлечения на написания регламентов и изменение концепции) программа была принята, а ещё через несколько месяцев внедрена и встала на боевое дежурство. К тому времени вследствие изменения внутренней структуры организации, изменения приоритетов и т.п., 75% написанного изначально ТЗ потеряла актуальность. Но это, на самом деле, не проблема. Проблема в том, что в погоне за скоростью написания софта все эти изменения не документировались. Соответственно, в настоящее время (да-да, оно до сих пор работает, что удивительно) софт может сопровождать ровно один человек, то есть я. А так как договора на сопровождение нет, то писать мне какие-то документы резона никакого нет (да и сам софт на дельфях). В результате раз в год они мне звонят, я правлю какие-нибудь мелочи сроком не более чем на неделю, и забываю об этом софте ещё на год.
Передать такое на поддержку куда бы то ни было принципиально невозможно. И именно эта история меня принудила предложить схему разделения ответственности между написанием техпроекта и софта, а также между написанием софта и его внедрением.
Итак, в нашей идеальной структуре потенциальные ошибки, подобные описанным в предыдущем пункте, должны будут фильтроваться дважды — при передаче документа от техписателей и при передаче софта внедренцам. Каждый срыв срока — предмет для разбирательства глав департаментов и менеджера проекта. Это совершенно чёткие вехи, от которых зависит проект. Более того, процессы с каждой стороны вех контролируются разными департаментами, что позволяет избегать размытия ответственности и передачу «на честном слове».
Производственная часть есть. Осталось добавить финдиректора, отдел АХО, юристов и эйчарню, и оргструктура нашей ИТ-компании готова.
Состав формируется как «представители отдела разработки под предводительством крутого специалиста из отдела проектирования ПО при поддержке методолога из группы матобеспечения под чутким контролем менеджера старательно удовлетворяют заказчика». Так что такой подход позволяет использовать не только «классический» водопад, но и гибкие технологии, где менеджер выступает как product owner. Единственно, это требует небольшого оверхеда на обратную связь с отделом технической документации, что не должно очень уж сильно тормозить процесс.
Исходя из пути проекта в нарисованной организации, а также разделения обязанностей на развитие, разработку и поддержку, получаем интересные следствия о личностных качествах руководителей этих отделов:
Так как я ни разу не управленец, а данная схема и обоснование — всего лишь плод размышлений «на тему», сильно прошу не бить ногами, а лучше высказать дельные замечания и конструктивную критику, которые весьма могут пригодиться другим.
Не так давно [около года — именно столько времени пролежала статья «в столе»] сидели мы с товарищем и думали за вопросы организации ИТ-компании. В реально большой ИТ-шной компании мы не работали, вся жизнь прошла в ИТ-подразделениях организаций, для которых ИТ — не основной вид бизнеса. Так что, хотя об организационной структуре мы представление имеем, с деталями её применения к приличных размеров конторе, чья жизнь — реализация и сопровождение софта, мы не знакомы.
Получилась после двух часов раздумий у нас примерно такая картинка, основные положения которой поясняются под катом.
Введение
Итак, у нас есть организация, которая ведёт достаточно крупные ИТ-проекты, внедряет их по стране, и много времени тратит на их поддержку. Также, из вводных, предполагаем, что бухгалтерия отдаётся на аутсорс.
Тут также имеет смысл упомянуть, что специфика в поддержке больших баз данных и систем обработки этих данных — есть уже несколько работающих решений, которые надо поддерживать.
Для начала распишем, что должна делать организация.
- Написание техзадания по списку техтребований и согласование их с заказчиком;
- создание полноценной технической документации (так как мы ориентируемся на последующее сопровождение проектов);
- проработка методологического и математического обеспечения;
- разработка архитектуры решения;
- создание софта;
- тестирование;
- внедрение;
- сопровождение.
Описание структуры
Каждый пункт это, фактически, отдел, хотя некоторые имеет смысл сложить вместе. Например, выпускное тестирование имеет смысл объединить с техдокументацией, а внедрение — с сопровождением.
Такому объединению есть несколько причин:
- Для отдела тестирования и технического документирования:
- интеграционное тестирование фактически проверяет программу на соответствие спецификации, т.е. техническому проекту;
- правильно определённая методика выпускного тестирования выявит не только фактические, но и логические ошибки — то есть когда программа не падает, но результат отличается от спроектированного;
- написанный софт выглядит как чёрный ящик, что позволяет абстрагироваться от его внутренностей;
- Для отдела внедрения и сопровождения:
- налаживаются контакты представителей техподдержки и представителей заказчика, так как внедрение и сопровождение «в одном флаконе»;
- «нулевое внедрение» производится на площадке тестировщиков, что позволит обкатать различные сценарии установки и получить боевой опыт дома.
Для такой схемы есть ещё одна причина, которая будет рассмотрена ниже.
С разработкой всё проще, есть отдел разработки системного и прикладного ПО, отдел веб-технологий, и выделен (так как большой объём работы с БД) отдел работы с БД.
Что касается разработки техзадания и заключения договоров — это типичные такие менеджеры, которые работают по проектному принципу с задачей «договориться с заказчиком, выдать задачи исполнителям, и следить чтобы всё было по графику». Директор наверняка будет с нетерпением ждать этих орлов в кабинете каждый отчётный период и ни за что не делегирует возможность дать им разгон своему заму.
Есть ещё пара пунктов, с которыми не совсем понятно. Это проработка математического обеспечения и разработка архитектуры софта.
Задача отдела матобеспечения — сформулировать методики, написать формулы, проработать методологию бизнес-процессов у заказчика. Этакий пул экспертов, досконально разбирающийся в теме, готовый дать решение по любому концептуальному вопросу.
Отдел проектирования ПО же, скорее, должен заниматься проработкой концептуальной целостности продукта, давать для отдела разработки скелет, который необходимо обтянуть мясом. Как проектный офис — место, где сидят менеджеры, так и отдел проектирования ПО — место, где сидят тимлиды.
Обе задачи не относятся ни к производственной, ни к операционной деятельности. Скорее, это некие отделы НИР, которые смотрят вперёд, собирают оптимальные решения, применяют их на практике и руководят разработкой.
Таким образом, получаем три ветки — развитие, разработка и техподдержка. Каждый проект проходит стадию инициации в проектном офисе, концептуальной проработки в департаменте развития, написания техдокументации в операционном департаменте, разработки, и затем передаётся опять в департамент сопровождения для внедрения.
Такой путь проекта теоретически должен позволить выявить концептуальные недостатки и фактические ошибки внутри организации, не вынося их к заказчику.
Тут требуется сделать небольшое лирическое отступление.
Давайте быстренько автоматизируем это!
В 2007м году поступило совершенно неформализованное задание «сделать им хорошо». После выяснения, кому именно и как именно надо «сделать хорошо», родился здоровый документ, в котором было всё это написано. Путь согласования документа, прямо скажем, был тернист и извилист, и учитывал интересы всех. Сейчас я понимаю, что, если это всё написать, получилась бы если не 1С, то что-то похожее; тогда мне это было совершенно неочевидно. «Ладно, — подумал я, — фигня, где наша не пропадала!..» — и сел за работу. Месяца через четыре был готов какой-то прототип, и я поехал его сдавать.
Выяснилось, что всё не так: то неудобно, это неверно, тут вообще бизнес-процесс поменялся… ну, в общем, я думаю, все могут представить эту ситуацию. Крякнув, я снова сел за работу.
Через несколько итераций (и после отвлечения на написания регламентов и изменение концепции) программа была принята, а ещё через несколько месяцев внедрена и встала на боевое дежурство. К тому времени вследствие изменения внутренней структуры организации, изменения приоритетов и т.п., 75% написанного изначально ТЗ потеряла актуальность. Но это, на самом деле, не проблема. Проблема в том, что в погоне за скоростью написания софта все эти изменения не документировались. Соответственно, в настоящее время (да-да, оно до сих пор работает, что удивительно) софт может сопровождать ровно один человек, то есть я. А так как договора на сопровождение нет, то писать мне какие-то документы резона никакого нет (да и сам софт на дельфях). В результате раз в год они мне звонят, я правлю какие-нибудь мелочи сроком не более чем на неделю, и забываю об этом софте ещё на год.
Передать такое на поддержку куда бы то ни было принципиально невозможно. И именно эта история меня принудила предложить схему разделения ответственности между написанием техпроекта и софта, а также между написанием софта и его внедрением.
Возвращаясь к оргструктуре
Итак, в нашей идеальной структуре потенциальные ошибки, подобные описанным в предыдущем пункте, должны будут фильтроваться дважды — при передаче документа от техписателей и при передаче софта внедренцам. Каждый срыв срока — предмет для разбирательства глав департаментов и менеджера проекта. Это совершенно чёткие вехи, от которых зависит проект. Более того, процессы с каждой стороны вех контролируются разными департаментами, что позволяет избегать размытия ответственности и передачу «на честном слове».
Производственная часть есть. Осталось добавить финдиректора, отдел АХО, юристов и эйчарню, и оргструктура нашей ИТ-компании готова.
О составе проектной команды
Состав формируется как «представители отдела разработки под предводительством крутого специалиста из отдела проектирования ПО при поддержке методолога из группы матобеспечения под чутким контролем менеджера старательно удовлетворяют заказчика». Так что такой подход позволяет использовать не только «классический» водопад, но и гибкие технологии, где менеджер выступает как product owner. Единственно, это требует небольшого оверхеда на обратную связь с отделом технической документации, что не должно очень уж сильно тормозить процесс.
Единство и борьба противоположностей
Исходя из пути проекта в нарисованной организации, а также разделения обязанностей на развитие, разработку и поддержку, получаем интересные следствия о личностных качествах руководителей этих отделов:
- Зам. директора по развитию — увлекающийся, с широким кругозором, всегда стремится к новым знаниям, новым технологиям. Его департамент почти всегда работает в чистый минус, но идеи, рождающиеся в нём, дают пищу остальным отделам, двигая компанию вперёд. Убеждённый оптимист.
- Зам. директора по операционной деятельности — осторожный, опытный работник, видящий всё на три шага вперёд, и потому скорее пессимист, хотя чаще всего обзываем ретроградом. Его департамент приносит стабильный, но небольшой доход, и он не хочет, чтобы из-за новых веяний инноватора всё пошло прахом.
- Зам. директора по производству — самый уравновешенный из всех, первый заместитель. Служит балансиром между инноватором и традиционалистом, придерживается эволюционной теории. Он приносит большую часть прибыли, обеспечивая всех бонусами, а директора — новой машиной, а потому спокоен.
- Финансовый директор — считает доходы и расходы и время от времени мягко напоминает инноватору, что если так пойдёт дальше, то директор не получит свой ежегодный порш кайен, а все остальные — свой бонус.
Заключение
Так как я ни разу не управленец, а данная схема и обоснование — всего лишь плод размышлений «на тему», сильно прошу не бить ногами, а лучше высказать дельные замечания и конструктивную критику, которые весьма могут пригодиться другим.
