Руководитель проекта - это не профессия. Надо еще работать.

Ссылка по теме:

1. 4 ключевые проблемы проектов внедрения 1С Предприятие

В ссылке по теме утверждается: "Ключевая проблема (неудачных проектов автоматизации, прим. ББ) в том что внедрением занимаются программисты. Хотя это задача управленческая". Я берусь доказать ровным счетом обратное:  ключевая проблема неудачных проектов автоматизации в том, что внедрением занимаются люди, ничего не понимающие в программировании.

Но начну я с отступления, прямого отношения к теме не имеющего, с терминологии. Так сложилось исторически, что программистами стали называть людей, чуть-чуть больше чем рядовые пользователи знающих и умеющих применительно к вычислительной технике, т.е. по сути продвинутых пользователей, которых в лучшем случае можно считать службой поддержки пользователей или консультантами, но никак не программистами. Здесь все просто, программист по определению - человек, создающий программы, и только такой. Придуман был термин для плохих программистов: "кодировщик" или "кодер". Под этим понимают специалиста, программирующего но ничего в предметной области не понимающего. Это тоже не программист. Это такая же нелепость как хирург, умеющий резать и зашивать, но не знающий что именно нужно "отмахнуть" у больного, и нужно ли вообще. Программист, автоматизирующий бухгалтерский учет, это бухгалтер, создающий САПР для схемотехников, это трассировщик печатных плат и т.д.

А вот теперь вернемся к проблемам проектов автоматизации. В статье по ссылке их четыре, по числу нарушенных правил. Первые две правила - это всего лишь организация процесса разработки.

Понятно, что в любом деле нужна элементарная организованность и дисциплина. Любой программист, даже работающий в одиночку, занимается планированием своих работ, устанавливает сроки, контролирует их, даже если все это существует только в его голове, а не в виде документов. Понятно, что если в проекте занято несколько программистов, то подход становится более формальным: регулярные совещания, фиксация планов "на бумаге", "разбор полетов" и т.д.   Но не надо организованность и дисциплину выдавать за отдельную профессию. Руководитель проекта - это не профессия, это скорее должность, как командир звена в авиации. Но также как командиром звена может быть только пилот, также и руководителем проекта может быть только программист. Программист может не быть руководителем проекта, если программистов на проекте несколько. Руководитель проекта не может не быть программистом.

Да, не каждый программист способен быть руководителем проекта. Потому что руководитель проекта - это организатор, а это уже не каждому дано. Потому что руководитель проекта - это еще и взаимодействие с заказчиком, т.е. выполнение всевозможных формальностей: заключение договора, принятие работ, согласование претензий, оплата работ  и т.д., а это тем более не каждому по силам. Но все-таки главная функция руководителя проекта - постановка задачи, потому что никто другой этого сделать не в состоянии. Заказчик выполнить постановку задачи не может, он может изложить свои "хотелки". Если это сделано в письменном виде и названо техническим заданием (ТЗ) - замечательно, но это не ТЗ. Это описание пожеланий, требований заказчика, его "хотелок", но не ТЗ. ТЗ, т.е. ТЕХНИЧЕСКОЕ задание, может составить только программист. Постановку задачи может выполнить только программист, исполняющий обязанности руководителя проекта, программист, понявший что хочет заказчик, что заказчику на самом деле нужно (уже не то же самое), обобщивший и (!) формализовавший пожелания заказчика.

Пример? Пожалуйста. Типовая конфигурация "1С: Управление торговлей ред.10.3". Типовой отчет по срокам задолженности покупателей на практике показывает неверные данные. Как ставит задачу заказчик: нам нужен другой отчет, правильный. Как ставит задачу грамотный программист - руководитель проекта: нужно изменить алгоритмы работы документов таким образом, чтобы регистр накопления содержал правильные данные и соответственно отчет - правильную информацию. Существующие алгоритмы работы документов сложны, методика работы с документами предъявляет к пользователям невыполнимые требования, поэтому их нужно изменить. Может такую постанову задачи выполнить руководитель проекта - не программист? Никогда.

Я хочу подчеркнуть, что ключевым понятием для вышестоящих абзацев является не ТЗ, а постановка задачи. Именно ошибки в постановке задачи, выполненной некомпетентным руководителем проекта, являются частыми причинами неудач. А в какой форме существует приложение к договору, описывающее содержание работ, в виде ТЗ, или в виде документа, написанного языком пользователя, это дело десятое.

Следующий тезис автора по ссылке - пользователям нужны инструкции, правильные инструкции - решение всех проблем, возникающих на пользовательском уровне. Это миф. А утверждение, что инструкция должна содержать "условия при которых процесс начинает ветвиться и вилять", это уже  утопия. Опять пример: может существовать два подхода к процессу обучения игре в шахматы. Первый: объяснить как играть отдельными фигурами и принципы их возможного взаимодействия. Второй: разбирать поведение игрока на примере конкретных позиций. Так вот комбинаций как в шахматах так и при использовании программ автоматизации даже не миллионы - миллиарды. Можно объяснить пользователю, что такое отчет "Оборотно-сальдовая ведомость по счету" (ОСВ), но нельзя описать все возможные случаи его применения. Писать инструкции о том, как получить остатки товаров с помощью ОСВ по счету "41", это идиотизм. Либо пользователь понимает, что ОСВ можно сформировать по любому счету, а остатки по товарам в бухучете - это остатки по счету "41", либо пользователь этого не понимает, но тогда уже ничем помочь нельзя. Все "ветвления" в инструкции не опишешь, и отсутствие у пользователя способности аналитически мыслить инструкцией не заменишь.

Утверждение о том, что инструкции от фирмы "1С" написаны для программистов, конечно же не верно. Видимо, автор ну очень далек от программирования. Инструкций для программистов по типовым конфигурациям фирмы "1С" просто не существует. Есть инструкции (я здесь сознательно использую терминологию моего оппонента) по платформе "1С: Предприятие", но не по конфигурациям. Такой инструкцией могло бы стать например описание системы учета НДС с подробным указанием назначения каждого регистра и поведения его регистраторов. Некоторые наброски подобного описания существуют на дисках ИТС, но не более чем наброски. А вот для пользователей как раз информации предостаточно, и с картинками и без, в том числе на тех же дисках ИТС, на ресурсах интернета, и не только от фирмы "1С". Но где те пользователи, которые это читают?

Программирование - всегда объектно-ориентированное (ООП). Я в данном  случае использую термин ООП не в узком, а в широком понимании. Я говорю не о наследственности объектов, а о способе мышления программиста. Все объекты в конфигурации - это объекты из жизни, это процессы. Что такое например документ "Поступление товаров и услуг", а его описание? Это как раз описание процесса поступления материальных ценностей. А если руководитель проекта этого не понимает, если он не умеет объектно-ориентированно мыслить, это то, с чего я начал: такой руководитель проекта - причина заваленного проекта. А руководитель проекта просто как посредник, как сводник -  в лучшем случае балласт.  

Статья получилась не столько рекомендательной, сколько опровергающей некоторые стереотипы, чему я впрочем рад, мастеров раздавать советы и без меня хватает.

PS: осталось пояснить некоторую странность названия статьи. Если не ошибаюсь, И.Ильфу и Е.Петрову принадлежит фраза: "Любовь к Советской власти - это не профессия. Надо еще работать." Во времена партийно-хозяйственной номенклатуры существовала такая профессия - руководитель. Сегодня руководит колхозом, завтра - авиапромом, послезавтра - пекарней. Результат известен. Не надо повторять ошибки, надо работать.