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

27.11.14

Управление проектом - Компетенции и навыки РП

Утверждается: ключевая проблема неудачных проектов автоматизации в том что внедрением занимаются программисты. Хотя это задача управленческая. Я берусь доказать ровным счетом
обратное.

 

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

  2. Топ 3 причин провала в проектах по внедрению 1С (Менеджеры продолжают навязывать свою точку зрения 27.11.2014)

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

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

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

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

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

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

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

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

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

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

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

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

руководитель проекта

См. также

Как быть эффективным руководителем проекта, а не экскурсоводом для команды стейкхолдеров

Компетенции и навыки РП Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    410    0    PChizhov    0    

5

Управление проектом Руководителем проекта со стороны Заказчика

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

Самый важный человек на проекте – это РП со стороны заказчика. Он принимает все решения и за эти решения зачастую отвечает головой. О том, кого выбрать руководителем проекта со стороны заказчика, как работать с заинтересованными сторонами, собрать рабочую группу, экономно расходовать бюджет и бороться с саботажем, расскажем в статье.

26.02.2024    777    0    user1270271    0    

11

Нужно ли аналитику 1С знать конфигурирование?

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    1186    0    otkalo    1    

6

5 основных внутренних ограничений руководителя

Компетенции и навыки РП Бесплатно (free)

В статье поделимся способами, которые помогут руководителям отойти от операционных дел в компании. Расскажем, как начать доверять сотрудникам и делегировать, зачем ставить гипотезы и экспериментировать, и главное – как развивать себя и преодолеть внутренние ограничения, которые мешают эффективности.

22.01.2024    966    0    andmakarov    2    

13

Риски, роли, книги и светлое будущее для ПМов: проектный дайджест #35

Компетенции и навыки РП Обучение и наставничество Инструменты управления проектом Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации vc, Хабра, Инфостарта (и не только) и выбрали самые крутые и полезные.

09.10.2023    804    0    Birby    0    

1

Методика оценки задач или Как «не угореть» по срокам

Компетенции и навыки РП Бесплатно (free)

Часто на проекте внедрения нужно понять, сколько времени уйдет на ту или иную задачу. От правильности расчета зависит, успеет ли разработчик сделать задачу в оговоренные часы или будет перерабатывать по ночам, и останется ли заказчик доволен стоимостью и сроками. Расскажем о простой методике расчета трудоемкости задач, которая позволит добиться оптимальных оценок и укрепить лояльность заказчика.

31.08.2023    2247    0    Midzgun    4    

12

Практика построения проектного офиса в ИТ-компании

Компетенции и навыки РП Бесплатно (free)

Процесс построения проектного офиса включает в себя не только организационную структуру, но и автоматизацию процессов, стандарты, KPI и мотивацию руководящего персонала и специалистов. Причем в ходе роста структуру регулярно приходится пересматривать из-за достижения лимита управляемости, внутренних и внешних факторов.

18.08.2023    2225    0    Pryamonosov    2    

6

Национальные особенности управления

Компетенции и навыки РП Бесплатно (free)

Внедрение проектного управления в России и странах СНГ пробуксовывает, и причина этому – национальные особенности, в том числе национальные особенности управления. Перечислим пять основных особенностей, которые мешают системно использовать проектные подходы в России, расскажем о том, как с этим работать и что поможет предотвратить риски.

17.08.2023    1425    0    paalferov    2    

18
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Alraune 1502 15.03.11 00:11 Сейчас в теме
Вроде, одна статья не противоречит другой. В той (которая как бы опровергается) говорится о том, что для внедрения нужны 3 ключевые роли: руководитель проекта, программист и специалисты по текущим процессам. А в этой, насколько я понимаю, просто подразумевается, что все эти роли должны сочетаться в одном человеке, но все равно нужны все. То есть отличие не принципиальное.
А насчет инструкций - да, пользователи, которые уповают только на них и не желают думать сами, - унылое зрелище. Все возможные ситуации в инструкцию не напишешь, да оно и не надо.
Kamikadze; +1 Ответить
34. 15.03.11 15:11 Сейчас в теме
ок. подкину дровишек для разогрева )))
1. Любителям и фанатам IBM посвящается: Написать программу может и дурак, а вот внедрить даже хорошую программу может только эксперт © http://www.microsoftproject.ru/articles.phtml?aid=70
2. В моей статье разделяются понятия "ТЗ на программирование" и "ТЗ на внедрение программы". Это ооочень важный момент )) Ни в один из своих проектов внедрения я не допускаю программиста к коду программы (они у меня только инструкции пишут и ошибки ищут). Если без изменения ПО ну ваще никак, стартую параллельный проект, куда выношу все изменения за отдельную плату и только после того как мне обоснуют их необходимость в цифрах, т.е. если это изменение позволит улучшить какой то важный и конкретный показатель организации и получить прибыль (все пожелания аля "ну без этого ваще никак" и "ну мне так удобно" идут под запись, но за рамки проекта). В статье рассматривается внедрение программ, тема проектов по программированию выходит за рамки статьи. То что уважаемая опозиция домыслила ряд идей, это проблемы опозиции )) Не надо мне приписывать ошибочные формулировки ))
3. В моей статье идет оперирование понятиями Роли (как верно заметила Alraune (1)) К термину Роль больше подходит термин Компетенция, чем термин Должность. Хочешь совмещай компетенции (роли) в одном специалисте, хошь - дроби... все зависит от ситуации. По должности ты можешь быть хоть техничкой по поддержанию санитарных норм в туалете, а по ночам хакером уносящим тонны килобаксов из ВТБ24 ))) Сейчас у меня в работе 25 проектов, где то я в роли руководителя, где то в роли программиста, где то в роли консультанта, а где то в 3-х ролях сразу. И как быть? Что же делать? )))
4. И как верно заметил Арчибальд (8) - беда в том что не у всех хватает силы регулировать восприятие сущностей на разных уровнях абстракции. Это проблема всех молодых или заблудившихся специалистов. С возрастом и опытом, если не заблудишься, эта способность появляется. А название должности значения не имеет. Будь ты программист, руководитель проекта, отдела, зам директора, директор или президент. Назвать себя можешь как душе угодно, внутренность и сущность от этого не поменяется ))
5. И вообще я ярый противник автоматизации... объяснительная тут ))) http://it-4-all.blogspot.com/2011/03/blog-post_10.html
krv2k; ZeBeR; RustIG; Spartan; +4 Ответить
35. KapasMordorov 428 15.03.11 15:34 Сейчас в теме
(34)
Программист, консультант - да какая разница? Они ж ресурсы.
Вот из небрежностей (сырых дровишек) и любых РП и получается провал.

- программист (специалист знакомый с программой, и тем как выглядят процессы при ее использовании, может привлекаться со стороны)
© A.Y.
39. 15.03.11 15:48 Сейчас в теме
(35) человек, дорогой, от куда ты взял эту мысль? подумай... в том что ты выделил в качестве цитаты этой мысли не было и быть не могло )
еще раз прошу не надо мусор из ваших голов приписывать к моим формулировкам.
40. KapasMordorov 428 15.03.11 16:15 Сейчас в теме
(39)
Почитал про Растам-ИТ, больше вопрос и замечаний не имею.
38. Spartan 365 15.03.11 15:37 Сейчас в теме
Пока писал свой пост, автор в (34) сам уже подтвердил мои предположения... :)
41. Арчибальд 2706 15.03.11 16:34 Сейчас в теме
(34) Ну вот, опять внедрение "TO BE". Особенно примечательно
только после того как мне обоснуют их необходимость в цифрах, т.е. если это изменение позволит улучшить какой то важный и конкретный показатель организации и получить прибыль
И это при том, что отнюдь не доказано, что внедрение данной компоненты проекта (которую хотят изменить)в неизмененном виде улучшит какой-то важный показатель.
Конечно, методически это правильно: отдельно внедряем то, что у нас есть "AS IS", говоря заказчику, что это и есть для него "TO BE". А потом уже за отдельную плату подгоняем то, что внедрили, под реальные потребности бизнеса (не хотелки, а именно потребности). Это нормальная позиция аутсорсера. Хлеб его.
М же ближе другая позиция, хотя тоже двухэтапная. Реальное проектирование системы с необходимыми отклонениями/добавками от того, что есть на рынке, включая отделение потребностей от хотелок, и создание этой системы (доведение функционала до потребностей бизнеса). Менеджер-непрограммист на этом этапе, скорее, навредит, чем поможет. Второй этап, внедрение, гораздо менее интересен с позиции творчества, и тут уж в самом деле программисты нужны только на исправление ошибок.
vkr; Трактор; Ish_2; +3 1 Ответить
45. 15.03.11 18:14 Сейчас в теме
(41) Арчибальд, ну не мне тебе рассказывать, что уж если выводить правила, то такие которые помогают в большинстве ситуаций.
И если внедрять 1С Бухгалтерию 8 или 1С ЗУП 8, то в большинстве ситуаций типовой функционал достаточен для запуска системы и выполнения первостепенных функций, для основных целей - экономия затрат, снижение ошибок, получение базовой информации и отчетов. Все остальное второстепенно и может ждать, потому выносится за проект.

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

Потому любые правила которые я обозначаю они нужны лишь для новичков и помогают лишь в статистическом большинстве ситуаций. Это не панацея и не закон нарушив который вас растреляют. Умеете решать задачи по другому - ваше дело. Я тоже не фанат правил, как своих так и чужих, и если вижу что в какой то ситуации правило которое помогало ранее навредит - я его убираю и действую без него или придумываю новое. Но такой подход не годится для новичков, т.к. их знания еще не достаточны для того чтобы жонглировать правилами в реальном времени... человеку который только входит в новую область знаний нужны конкретные инструкции.

И если человек которого волею судьбы поставили ответственным за сложную задачу - создать информационную систему, будет искать подсказку, то что ему поможет? Эта опозиционная отрыжка в виде попытки назвать руководителей бесполезными людьми или моя статья которая дает конкретные подсказки?
ShestakovVitaly; Anything; Spartan; +3 Ответить
59. Арчибальд 2706 16.03.11 07:47 Сейчас в теме
(45) А я, собственно, и не возражаю. Не бывает универсальных рецептов. И те два подхода, в 41 посте, я не противопоставлял, а сопоставлял. В реальности они вряд ли встречаются "в чистом виде". Если автоматизация начинается "с нуля", от арифмометров - первый подход должен превалировать. И совершенно другая ситуация, когда предстоит переход от ПУБ к КА. Там с большой вероятностью продуктивнее будет второй вариант.
248. drkhaired 51 25.09.18 15:07 Сейчас в теме
(34)
они у меня только инструкции пишут и ошибки ищут


Либо у вас не программисты в команде, либо вы им очень хорошо платите. Я не знаю ни одного программиста (именно программиста), который бы устроился в штат "писать инструкции".
244. Kamikadze 46 28.02.13 13:18 Сейчас в теме
(1) Alraune, Соласен полностью. для себя вынес рациональные зерна с одной и другой статьи.

Я пишу инструкции конкретные: если документ - то для чего его использовать, если отчет - то что оно показывает. остальное - разумный пользователь сам догадается. А вот если работа постоена на процессном подходе - тогда нужно описывать для каждого участника процесса его работу на своем уровне.
2. sturman1986 15.03.11 00:27 Сейчас в теме
На самом деле автор описал текущую ситуацию, что около 80% руководителей проектов сейчас это люди с минимум опыта или программиста или консультанта, под минимумом подразумеваю около 1-3-х лет работы и обладающего самыми минимальными знаниями в предметной среде. Почему то считается что руководитель проекта это на 90% менеджер и только чуть чуть программист или консультант в какой то сфере. Однако мы забываем что внедрение (именно проектное, крупное) - это прежде всего работа, связанная с использованием качественного портфеля знаний и с учетом российский реалий знаний в нескольких предметных областях. Как мне видится успешность проекта это прежде всего ключевое понимание роли, задач подрядчика и заказчика в проекте и именно на руководителя проекта ложится понимание общей концепции проекта. А с таким багажом знаний как у большинства поэтому и случается так что большая часть проектов движется со скрипом и постоянными срачками. За сравнением далеко ходить не надо, как думаете может руководить аудиторской проверкой человек обладающий знаниями ниже чем рядовые аудиторы, будь он хоть супер менеджером? нет, так и в любой сфере консалтинга. А в 1С пожалуйста.
3. bb1962 990 15.03.11 06:11 Сейчас в теме
Alraune пишет:
Вроде, одна статья не противоречит другой.

Противоречит. Цитирую оппонента: "пойдет любой человек с организаторскими компетенциями который сможет выполнить остальные 3 пункта."
Как раз организаторов, способных устраиваить "еженедельные совещания", предостаточно, профессионалов не хватает.
Егор_Динин; +1 Ответить
4. Арчибальд 2706 15.03.11 08:08 Сейчас в теме
Не удержусь от повторения своего же комментария к статье "4 ключевые..."

Если руководитель посчитает, что ему требуется реинжиниринг, тогда он обратится в реинжиниронговую фирму, и там с него сдерут немерянное бабло за консультации и столь же немерянное на покупку автоматизированной системы "To be" (как правило, эти фирмы знают, что "надо" внедрять, еще не знакомясь с заказчиком). Затем сумма возрастет еще в два-три раза за внедрение. Начнется текучка кадров. И долгий процесс восстановления разрушенного управления/учета.
ИначеЕсли руководитель осознает, что автоматизация хаоса прводит к автоматизированному хаосу, он найдет и возьмет себе в штат квалифицированного автоматизатора, с помощью которого предотвратит развод фирмы на бабки и наведет порядок в своих бизнес-процессах таким способом, что "левых" внедренцев приглашать не придется. ИМХО (в смысле, КонецЕсли)

Может ли проект, возглавляемый менеджером, быть успешным?
Может в двух случаях
1) Менеджер ничего не понимает в информатике и полностью полагается на ведущего программиста.
2) Ведущий программист имеет право вето на любые идеи руководителя проекта, который якобы что-то в информатике понимает.
Конечно, оба варианта не гарантируют успеха. В любом случае ведущий программист проекта должен быть упомянутым квалифицированным автоматизатором, а не "крутым кодером".

ОФФ. На заре моей автоматизаторской деятельности нас обязали еженедельно планировать и учитывать рабочее время. И старый мудрый начлаб посоветовал мне отводить 60-80 процентов времени на ликвидацию последствий вмешательства высокого начальства - в современной терминологии, руководителя проекта.
Прилагаю аватарку для статьи :)
Прикрепленные файлы:
EdmundoAlvares; SirYozha; Alraune; RustIG; +4 Ответить
5. bb1962 990 15.03.11 09:46 Сейчас в теме
Арчибальд пишет:
Может ли проект, возглавляемый менеджером, быть успешным?

Еще не факт, что в описанной ситуации ведущий программист захочет брать на себя
обязанности руководителя проекта и тащить на себе целую гирлянду спиногрызов.
Так что ТОЛЬКО увеличение стоимости проекта - это в лучшем случае.
6. RustIG 1351 15.03.11 09:51 Сейчас в теме
У кого-нибудь есть примеры проектов, в которых РП не "из программистов"?
Мне пока не ясно - актуален ли данный "разбор полетов"?
7. bb1962 990 15.03.11 10:04 Сейчас в теме
(6)
Судя по количеству плюсов, которые получила статья http://infostart.ru/public/71671/,
таких примеров предостаточно.
Я так понимаю, что каждый проголосовавший согласен с доводами автора этой статьи.
8. Арчибальд 2706 15.03.11 10:25 Сейчас в теме
(7) Не так. Я тоже поставил плюс за ту статью, однако как рекомендацию к прочтению/размышлению, а не как согласие с содержанием. Мне ближе позиция этой статьи, и именно в том плане, что хороший программист - это уже руководитель, поскольку постоянно принимает решения в условиях неопределенности, а также способен к абстракции - увидеть сущность объекта/процесса (в статье упоминается ООП в широком смысле) под наслоением малозначимой атрибутики. Нужно только научиться организовать работу команды ("надо работать").
(6) Я сам с командой делал проект большой и успешный. Но там руководитель проекта только орал при задержке этапов и выбивал/предоставлял ресурсы. Т.е. как в 1) моего 4-го поста.
Irwin; ula1c; Yashazz; RustIG; +4 Ответить
12. bb1962 990 15.03.11 10:52 Сейчас в теме
(8)(9) Тогда нужно изменять систему голосования, иначе не понять кто за, кто против.
Статья моего оппонента не дискуссионная, это не призыв к обсуждению, это
УТВЕРЖДЕНИЕ.
14. Alraune 1502 15.03.11 11:03 Сейчас в теме
(12)
Поставьте плюс, если вы рекомендуете данную публикацию к прочтению и использованию

А комментарии как раз и нужны, что понять, кто за и против. Тем более в комментариях к той статье тоже развернулось немаленькое обсуждение.
15. Арчибальд 2706 15.03.11 11:03 Сейчас в теме
(12)
Статья моего оппонента не дискуссионная, это не призыв к обсуждению, это
УТВЕРЖДЕНИЕ.
Но обсуждение из 138 постов все же случилось ;)
(13) Компьютер должен работать, а человек - думать.
9. Alraune 1502 15.03.11 10:36 Сейчас в теме
(7) Мой плюс тоже и там, и там. Публикация как повод к размышлению и обсуждению часто заслуживает плюса вне зависимости от того, разделяю я мнение автора или нет.
17. tango 506 15.03.11 11:13 Сейчас в теме
19. Арчибальд 2706 15.03.11 11:31 Сейчас в теме
36. Spartan 365 15.03.11 15:35 Сейчас в теме
Что хочется сказать... Если не впадать в крайности, то можно прочитать обе статьи более внимательно и не найти в них по-настоящему значимых противоречий, а объединив и выделив из них самое важное / полезное - получить более полную и подробную картину внедрения. Во всяком случае лично я особых поводов для противостояния не вижу...
Руководитель проекта конечно должен разбираться в программировании, понимать и представлять себе как возможно решить ту или иную задачу в конкретной системе учета. Это не может быть только менеджер, но в первой статье нигде и не говорится, что он должен быть исключительно им. При этом РП должен обладать и управленческими (организационными) навыками, и с этим тоже нельзя спорить - "обычный" программист ("кодер") с этой ролью не справится. Собственно в этой основополагающей причине спора я особых расхождений не нашел: есть подозрение, что авторы говорят немного о разных вещах в одной терминологии. В первой статье всего навсего речь идет больше об "управленческой" стороне процесса... да и первая статья скорее больше инструкция по внедрению (именно как правильно организовать рабочий процесс), здесь же больше мысли о сути вещей... О деталях (вроде инструкций) конечно можно спорить.
(17) Основываясь на вышесказанном, считаю, что минус не заслужен.
16. tango 506 15.03.11 11:11 Сейчас в теме
(6) есть, есть, мое предпоследнее место работы - БТК: крутецкий оптовик всего, что втыкается в розетку, не менее двух лет БиТ сосал бабло, УТ+Инталев, в результате одного ключевого пользователя (продажника) уволили, другой (финдир) в конце проекта писал "все проводки неправильные", прогнали битовцев, уволили всех. кого брали на подхват. начали сокращать своих штатных 1снегов, завели речи о возврате на 7.7
руководитель от БиТа "Кирилл Гусев":mailto:kgusev@1cbit.ru
18. tango 506 15.03.11 11:24 Сейчас в теме
+(16) форма расходного ордера на определенную выплату содержала пять (пять!) разных реквизитов, которые должен был заполнить оператор, чтобы указать системе, что это ордер именно на такого рода определенную выплату
10. yangusarov 15.03.11 10:47 Сейчас в теме
Зэ бэст оф зэ бэст - это когда руководитель проекта + хороший программист-внедренец = хэппи енд проект.
11. RustIG 1351 15.03.11 10:47 Сейчас в теме
я успел поработать в команде, где, во-первых, РП был, и был он одновременно и кодером, и постановщиком ТЗ, и аналитиком, и составителем договоров, и тестировщиком у своих подчиненных программистов, при этом эти же программисты были одновременно немного аналитиками, тестировщиками, документаторами, кодерами, внедренцами. затем я работал в команде, где эти функции были четко разделены: есть аналитики (одновременно и тестировщики), есть документаторы, есть разработчики, есть постановщики ТЗ, есть свои внедренцы, проект-менеджеры и руководитель отдела, но вот РП не было. может спор из-за терминологий?
13. cool.vlad4 2 15.03.11 10:57 Сейчас в теме
"Надо еще и работать" ... :D Надо распечатать и повесить в своем кабинете...
20. cool.vlad4 2 15.03.11 11:49 Сейчас в теме
вывод-то в итоге какой? надо работать? ..ли...
21. Арчибальд 2706 15.03.11 11:57 Сейчас в теме
22. bb1962 990 15.03.11 12:15 Сейчас в теме
(20) Надо. В том числе надо "работать" с теми, кто мешает.
С теми, кто занимает чужое место, кто присваивает
себе кем то заработанное. Это уже отдает политикой, но без этого никак.
23. vkr 15.03.11 12:25 Сейчас в теме
+512 !!!

2 All
Уважаемые коллеги, наверное, многим будет интересно прочесть книгу
Фредерика Брукса "Мифический человеко-месяц, или Как создаются программные системы"
(Frederick P. Brooks, The Mythical Man-Month).

Брукс - профессор вычислительной техники, известен, прежде всего, как "отец IBM System/360" (кто знает - поймет :) ).
В США полагают, что без прочтения книги Брукса не может состояться ни один руководитель программного проекта.
---
А если взять нашу, российскую реальность, то, ес-сно, когда босс ни черта не понимает в разработке,
ориентирован только на зарабатывание "буказоидов", и при слове "ТЗ" впадает в ступор, то можно легко представить
итоговое качество и сроки проекта... :)
Еще раз - ОГРОМНОЕ СПАСИБО автору !!!
Yakud3a; zinch; RustIG; +3 Ответить
26. bb1962 990 15.03.11 12:56 Сейчас в теме
(24)(25) Может быть все-таки почаще в отладчике тексты читать?
28. cool.vlad4 2 15.03.11 13:14 Сейчас в теме
(26)?
Прикрепленные файлы:
27. Арчибальд 2706 15.03.11 13:06 Сейчас в теме
(23) (24) (25) На Инфостарте есть все
http://infostart.ru/public/72612/ ;)
cool.vlad4; +1 Ответить
29. vkr 15.03.11 13:52 Сейчас в теме
(27) Лучше уж тогда - с картинками :), вот отсюда :
"Мифический человеко-месяц..." (в формате PDF, 1.5Мб)
30. Арчибальд 2706 15.03.11 14:07 Сейчас в теме
(29) У меня именно с картинками. Из юбилейного издания 95 года
31. cool.vlad4 2 15.03.11 14:21 Сейчас в теме
(29) на либрусеке вообще-то с картинками ...добавлять некогда было в архив...
32. Alraune 1502 15.03.11 14:36 Сейчас в теме
(31) С картинками, да. Сейчас сижу, читаю. Спасибо за ссылку)))
25. cool.vlad4 2 15.03.11 12:49 Сейчас в теме
Прикрепленные файлы:
mithsoftware.rar
fomix; sergeevcorp; RustIG; Alraune; +4 Ответить
33. tango 506 15.03.11 14:56 Сейчас в теме
из Брукса, в поддержку (0) :
"Вывод прост: если над проектом работают 200 человек, включая менеджеров, являющихся наиболее знающими и опытными программистами, увольте 175 бойцов, и пусть менеджеры снова займутся программированием."
YVolohov; +1 Ответить
37. Spartan 365 15.03.11 15:37 Сейчас в теме
42. awk 741 15.03.11 16:41 Сейчас в теме
Позволю внести свои пять копеек:

Руководитель пишущий код - плохой руководитель. Это не означает, что он не должен уметь это делать, это означает, что он находится не на своем месте. Если руководитель работает за подчиненного (а написание кода это работа за программиста) может означать только два варианта:

1. Нехватка ресурсов.
2. Ненужность руководителя.

Первый вариант должен решаться в кратчайшие сроки, а его наличие считаться форс-мажором. А второй вариант говорит сам за себя - проект тривиален и не требует столько ресурсов сколько потребляет.
dabu-dabu; cool.vlad4; +2 1 Ответить
43. Трактор 1246 15.03.11 16:57 Сейчас в теме
(42)
Руководитель пишущий код - плохой руководитель.
...
1. Нехватка ресурсов.
2. Ненужность руководителя.

Если на проекте больше одного исполнителя, то нужен руководитель. Выделять отдельного человека на руководство не всегда целесообразно. Совместительство требуется в большинстве случаев.
cool.vlad4; Spartan; +2 Ответить
44. awk 741 15.03.11 18:12 Сейчас в теме
(43) Это не руководитель - это координатор. Не надо теплое с мягким путать. Координатором и секретарь может быть.
46. Трактор 1246 15.03.11 18:19 Сейчас в теме
(44) Руководитель тот кто несёт ответственность за деятельность бригады, команды, группы, отдела. Если он при этом совмещает руководство с производственной деятельностью, то это руководитель по совместительству. А так получается что ты просто не признаёшь существование совместительства.
49. awk 741 15.03.11 18:43 Сейчас в теме
(46) Более того я не только его признаю, но и описываю ситуации возникновения данного явления. Один из которых - это простота проекта, при которой исполнитель может попеременно исполнять разные роли. Половина людей на этом сайте приходя к клиенту играют роль менеджера по продажам, сев за компьютер - руководителя, технического писателя, программиста, тестировщика (роль о которой все забыли), а вернувшись к клиенту с результатами - роль внедренца. Дальше больше - они начинают играть роль тех. поддержки.

А когда мы по совместительству работаем? Ответ только один - когда экономим мы, или экономят на нас. Отсюда и мое отношение к совместительству. Это либо жадность клиента, либо жадность исполнителя (руководителя). А любая жадность - это дефицит, а почему СССР развалилось? Потому что дефицит был (не только из-за этого конечно, но и из-за этого то же). Пока проект мал (или мало проектов) - жадность работает на нас, как только проект растет (размножается) - жадность играет против нас.

Мое мнение РП требуется не тогда, когда появляется второй (третий, десятый) программист, а когда появляется команда (пусть и из двух человек) которой надо управлять (принуждать к определенным действиям, для получения результата). Однако хорошим руководителем я считаю только того, кто может встать(а не встает) на место подчиненного и выполнить за него работу, прикрывая тем самым случаи форс-мажоров.
dachnik; vkr; +2 Ответить
51. Трактор 1246 15.03.11 20:51 Сейчас в теме
(49)
Отсюда и мое отношение к совместительству. Это либо жадность клиента, либо жадность исполнителя (руководителя).
И что ни разу на проекте не требовалось 1,5 программера и 0,5 рукля? Ой не верю! А если потребуется, то клиент будет платить за двух программистов и одного рукля. Накладненько выходит. При избытке клиентов, конечно, можно одного рукля нагрузить несколькими проектами, но так бывает не всегда.

Более того, рукль, который умеет кодить, но не кодит, со временем теряет квалификацию. Разучивается.
Anything; Spartan; +2 Ответить
52. awk 741 16.03.11 00:05 Сейчас в теме
(51) Уж прости, но не бывает "полтора землекопа". Их либо два, либо один. Либо у проекта дефицит, либо профицит, либо проектов более одного.
53. Трактор 1246 16.03.11 00:16 Сейчас в теме
(52)
не бывает "полтора землекопа"
Ещё более не бывает людей, умеющих программировать, но не программирующих. Твоё пожелание о том что рукль проекта должен уметь
встать(а не встает) на место подчиненного и выполнить за него работу
, но только в форс-мажоре. Или форс-мажоры должны быть постоянными или квалификация такого специалиста быстро упадёт.
54. awk 741 16.03.11 01:23 Сейчас в теме
(53)Да тут ты прав - со временем она падает (как программиста), зато растет как руководителя и форс-мажеры случаются редко. Для себя я принял правило - не писать где руковожу и не руководить где пишу. Пока помогает. Правда, пишу все реже и чаще для себя (автоматизация средств атоматизации).
55. bb1962 990 16.03.11 06:03 Сейчас в теме
(54)
awk пишет:
Правда, пишу все реже и чаще для себя

Это всего лишь возраст, чем бы Вы себя не утешали.
Не всем дано быть программистами до 60-ти.
Это не хорошо и не плохо, это - жизнь.
56. 16.03.11 06:17 Сейчас в теме
(54) У меня похожее правило, только оно называется так: приступать к выполнению конкретных задач, только если загружены все участники, в соответствии с приоритетами. Пока кто то начал уходить от приоритетов или халтурить - ищу причины, устраняю - это первостепенная обязанность если ты взял на себя ответственность за результат.

И если участники все заняты своими делами, тогда приступаю к выполнению сам, беру как правило те задачи, которые не потянуть не программистам, не консультантам. Это или конфликты или политика или улаживание противоречий между различными сторонами. Ну а когда время освобождается на старое и доброе программирование так что получается уйти в него с головой и не думать о течении проектов, ну это почти что праздник души ))
47. 15.03.11 18:32 Сейчас в теме
Ответственность штука сложная. На много сложнее взять на себя ответственность и выполнить обязательства любой ценой.
Гораздо проще мнить себя пупом земли, выполнять свои должностные инструкции, и дальше мониторов не заглядывать.
А управление это способность достигать результатов. Что для этого нужно? Да все!
Надо - глав.буха соблазнишь, надо - столы потаскаешь, в гостиницах без отопления поспишь, в самолетах полетаешь без передышки неделю, выслушаешь какой ты козел от 8 из 10 сотрудников, пару ночей без сна перебьешься перед закрытием проекта...
И все эти особенности как правило знают лишь те кому приходилось нюхать такое слово как ответственность, чтобы зарплату получали те кто кроме программирования в этой жизни ничего не хочет.
blackschool; RG-Soft; +2 Ответить
48. cool.vlad4 2 15.03.11 18:36 Сейчас в теме
"Наилучший руководитель - тот, о котором люди знают только, что он существует. Когда его работа выполнена, они скажут: ‘Мы сделали это сами’". ( Лао Цзы)
50. tango 506 15.03.11 20:42 Сейчас в теме
не возьму за чужую голову, что там как, в 1с "внедрить типовуху" до сих пор называлось "сервис-инженер"
большинство присутствующих, имхо, под "проектом" имеет иное
57. 16.03.11 06:24 Сейчас в теме
(50) ну так а ты возьми общепризнанные определения
тут http://it-4-all.blogspot.com/2011/01/blog-post_31.html
или тут более просто и красиво http://it-4-all.blogspot.com/2011/03/blog-post_7981.html

+ Учти что проект проекту рознь. одно дело "внедрить" 1С БП 8 Базовую там где 1 гл.бух сидит из всей бухгалтерии. Там ей пару вводных расказал, инструкции сунул - дальше она сама. Другое дело внедрить ту же БП или ЗУП на предприятии в 500 человек, со штатом бухгалтеров (читай - пользователей) - человек 20.
Но даже эти проекты можно считать относительно простыми, если суметь удержать рамки.
А вот если взять проекты где 1000 пользователей... то там скулы трещат по швам и на пару лет приходится забыть про личную жизнь.

Сунь туда своего сервис-инженера или программистов-фанатиков (которых хлебом не корми дай попрограммировать) без компетенций по управлению и посмотри что станет с проектом.
Сервис инженер загнется после первого же конфликта сторон, проргаммист не сумеет выдержать рамок, начнет изменять программу и проект начнет растекаться как понос. К дате окончания контракта выяснится что результатов нет и система в состоянии не стояния - хотя вроде программировали днями и ночами.
60. tango 506 16.03.11 09:22 Сейчас в теме
общепризнанные = признанные мной - позиция ожидаемая.

походу ты так и не понял, что расхождение в одном пункте, но принципиальном:
РП должен уметь программировать (в данном случае - в 1с), просто потому, что он - архитектор системы

разумеется, что речь не идет о "типовых" внедрениях

**
минус в (57) - за голимую саморекламу
61. Арчибальд 2706 16.03.11 09:32 Сейчас в теме
(60) А нужен ли архитектор при строительстве хрущоб? Там прораба достаточно.
62. vkr 16.03.11 09:41 Сейчас в теме
(61) Присоединяюсь!
А нужно ли вообще строить хрущобы ?
Может, немного подумать головой и построить что-то получше - где и архитектор нужен ? :)
64. tango 506 16.03.11 09:46 Сейчас в теме
(61),(62)
tango пишет:
разумеется, что речь не идет о "типовых" внедрениях


пример "эффективного менеджера" : чубайс - авария в СШ, цены на энергию
69. awk 741 16.03.11 11:08 Сейчас в теме
(60) Архитектор и руководитель - это разные роли. Одна роль отвечает на вопрос: "Как может быть?", а вторая: "Как это будет достигнуто?". В одном человеке роли совпадают до тех пор, пока проект мал (или мало проектов).
70. tango 506 16.03.11 11:29 Сейчас в теме
(69) стройка. есть архитектор (Как может быть). есть прораб (Как это будет достигнуто). Вы не путаете производителя работ с руководителем проекта?
Королев - что бы сделал, не будь инженером?
И еще раз - чубас - ...
73. awk 741 16.03.11 11:51 Сейчас в теме
(70) Давайте подытожим роли:

1. Заказчик (Сколько денег?)
2. Руководитель проекта (Как работать?)
3. Архитектор (Что делать, не вдаваясь в детали?)
4. Ведущие программисты (инженеры по оборудованию) (Как реализовать детали? На чем будет работать?)
5. Тестировщики (Работает?)
6. Тех. писатели (Как помочь?)
7. Внедренцы (Как обучить пользователя?)
8. Тех. поддержка (Как обеспечить гарантию (бесперебойную работу)?)


Я забыл наверняка что-нибудь - подправьте если не сложно.
74. vkr 16.03.11 12:19 Сейчас в теме
(73) 1. Заказчик - ЧТО (в первую очередь!) / Зачем (цель проекта) / Когда (сроки) / Почём...
2. Руководитель проекта - Что / Зачем (цель проекта) / Кто (коллектив) / Когда / Почём
3. Архитектор - Что (вдаваясь в детали!) / Зачем / Когда / На чём
78. awk 741 16.03.11 12:28 Сейчас в теме
(74) Заблуждаетесь. Заказчик никогда не знает что ему нужно, в какие сроки это будет сделано, какова себестоимость. Он может ответить только на вопрос сколько он готов заплатить и кому.
80. tango 506 16.03.11 12:30 Сейчас в теме
+(78) ... кому конкретно. тендер, понимаешь
81. awk 741 16.03.11 12:40 Сейчас в теме
(80) Забыл в (73) роль "Менеджер по продажам (Как объяснить клиенту, что это надо делать за N$ период Т и в конторе "Рога и копыта" :))" - позор на мои седые волосы...
82. vkr 16.03.11 12:47 Сейчас в теме
(78) Я, конечно понимаю смысл Вашего возражения - в контексте книжек типа "Физики шутят"... :)
Но ведь, по большому счету, нормальный заказчик знает - ЧТО он хочет получить (eg, систему учета "Рога и копыта"),
срок и примерную сумму, за которые он хочет это получить. А уж на сколько его попытаются развести - бог знает...
Наверное, если руководитель проекта - из программеров, то заказчику будет легче... В России, по крайней мере... :)
83. awk 741 16.03.11 13:07 Сейчас в теме
(82) Не так... Заказчик обращается к автоматизатору по двум причинам:

1. Наличие свободных средств.
2. Попытка решить ряд проблем.

В первом случае - это автоматизация ради автоматизации ("Мне такую же, но с перламутровыми пуговицами"), давайте не будем рассматривать - это не проектная работа, а развод клиента на бабки (кстати полезна для клиента - аля пьявки).

Во втором случае - клиент не знает, что хочет (где у него проблема) т.к. решил бы ее сам, а не обращался на сторону.
87. vkr 16.03.11 14:49 Сейчас в теме
(83) По первому пункту - согласен. По второму - нет.
Клиент может прекрасно знать - В ЧЕМ у него проблема (авто не едет, костюмчик жмет, система не так считает),
но решить ее САМ (как Вы правильно отметили) не в состоянии - попросту в силу того, что не умеет этого сделать...
Вы же сами не управляете самолетом, когда летите в отпуск на Канары :), хотя можете в тонкостях разбираться
в теории аэродинамики...
Но, наверное, наша дискуссия уже ушла от темы...
58. 16.03.11 06:35 Сейчас в теме
и еще добавлю ) в комментах я пишу не для того чтобы убедить себя или вас )
просто у меня посещаемость на блоге подскочила, подключение людей в группы и рейтинг моей статьи начал расти. я не мог понять почему )
а потом один из программистов (один из не многих кого я уважаю) кинул мне статью на этот холиварчик и я решил подкинуть дровишек ))
а себе я уже давно все доказал (с) В.Высоцкий
1. Почему предприниматель, организатор и специалист нужны друг другу? http://it-4-all.blogspot.com/2009/12/blog-post_02.html
2. Стадии роста специалиста по ИТ http://it-4-all.blogspot.com/2010/03/blog-post_12.html
66. vkr 16.03.11 09:50 Сейчас в теме
(58) К Вашему пункту 2 ("Стадии роста...") :
6. Просветление. Прошедши сквозь стадии 1-5, и поняв, что более заняться нечем,
начинает блогосферную деятельность...
Sorry. "it was just business, not personal"
63. warden 101 16.03.11 09:44 Сейчас в теме
Написано разумно. Единственное, есть непонимание некоторых нюансов. Они не столь банальны, так что это простительно.
не надо организованность и дисциплину выдавать за отдельную профессию. Руководитель проекта - это не профессия, это скорее должность

Руководитель - действительно не профессия. Это способность. И тот, кто этого не может, никогда не поймет, что означает руководить. Что значит "взять на себя ответственность". Или "организовать рабочий процесс". Я могу таких понятий накидать много, но грамотный управленец отличается тем, что видит и делает все это сразу, в комплексе, а вот тот, кто смотрит снизу, увидит только "регулярные совещания".
если в проекте занято несколько программистов, то подход становится более формальным

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

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

Напоминает старый анекдот "х...ню мы не лечим, а п....ц неизлечим". Вам ведь не надо напоминать про квалификацию врача, сказавшего эти слова? Открою секрет - нормальные, грамотные руководства пользователей - существуют. Их можно и здесь найти. Если только! - задаться вопросом "а поймут ли вас пользователи?" К сожалению, пока я вижу, что этим вопросом Вы даже не планируете задаваться.
К слову, сам я программист. Повидал и хороших и плохих руководителей. И хороших и плохих программистов. Экзистенциальная позиция автора мне тоже знакома хорошо, а ИТ среде это, к сожалению, не редкость. Впрочем, специфика профессии такова.
Anything; Трактор; +2 Ответить
65. tango 506 16.03.11 09:50 Сейчас в теме
(63) и другие:
Что значит "взять на себя ответственность"

расшифруйте, плиз

при Сталине просто - не справился - расстреляли

потом расстрелы убрали, а "товарищи" остались

конкретно, в чем заключалась ваша ответственность как РП, во-первых, перед подчиненными, во-вторых, перед заказчиком.
конкретно - ваша, и конкретно - сколько
ну, т.е, ваши подчиненные знали, что если проект провалится, вы ответите конкретной суммой денег?
67. warden 101 16.03.11 10:09 Сейчас в теме
(65) "Взять ответственность" - вот тут как раз пока не "возьмешь", не поймешь :D И обьяснить невозможно.
Те, кто реально руководит, организует, а не сидит на должности, поймут. И еще те, кто занялся своим бизнесом. Остальным могу сказать только - попробуйте.
Вот описать типичные проблемы при этом - это пожалуйста - кто-то не знает "как делать", кто-то не знает "что делать", в смысле куда двигаться. В результате как раз и мало людей, способных это сделать.

Что еще хотелось бы добавить по поводу статьи - из собственного опыта - профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот. Наш брат даже с себе подобными иногда не может найти общего языка :D
68. tango 506 16.03.11 10:29 Сейчас в теме
(67) "И обьяснить невозможно." vs "профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот"

ну, я так понял, что ответственность ваша носит некий нематериальный характер.
собственно, это и есть и причина развала союза, и провалов 1сных проектов
72. warden 101 16.03.11 11:41 Сейчас в теме
tango пишет:
(67) "И обьяснить невозможно." vs"профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот"

Все правильно, я программист, а не управленец, в чем сразу и признался :D Просто я понимаю, в чем разница, а вот обьяснить Вам, что значит "управлять"... Образно говоря, Вы просите меня обьяснить Вам "как научиться плавать" или даже "что значит плавать", а обьяснить это нельзя в принципе, понять это можно лишь начав плавать. И то, научиться этому - это одно, а получать от этого удовольствие и сделать это частью своей жизни - совсем другое, может, Вам это и не подойдет.
tango пишет:
собственно, это и есть и причина развала союза, и провалов 1сных проектов

А я еще про комитет 300 слышал, и про зеленых человечков :D
Если серьезно, то не торопитесь обобщать, прилив позитивных эмоций людям Вы, конечно, обеспечите, весь вопрос - а что это даст Вам?

Я, может быть, не очень четко указал центральный посыл своей идеи - я, в противоположность автору статьи, считаю, что руководитель проекта не обязательно должен быть хорошим программистом, а вот хорошим руководителем он должен быть обязательно. Обосную - грамотный руководитель может плохих исполнителей и поменять, а вот при плохом руководителе и хорошие сотрудники могут каши не сварить. Подчеркну - "может" не значит "будет". Просто шанс успешного доведения проекта на порядок выше.
Сразу могу ответить на первое возражение: "а как он разберется, где хороший программист, а где нет?". Ответ: сам - никак. Но на моей памяти хорошие управленцы всегда имеют множество хороших знакомых специалистов в самых разных областях, и в том числе в ИТ сфере, способных верно оценить потенциал сотрудника. И не припомню ни одного случая, когда бы хороший управленец принял на работу плохого программиста. Больше того, куча примеров, когда толковый начальник ИТ отдела вообще в 1С не шарил ну просто никак, при этом никаких проблем в этой сфере не было, все решалось очень быстро и эффективно.
76. tango 506 16.03.11 12:24 Сейчас в теме
(72) еще одна характерная примета: "вот обьяснить Вам, что значит "управлять""

я не просил объяснять это, я просил (риторически) сказать, в чем заключается ваша "ответственность", из-за которой ушей не видно.
84. warden 101 16.03.11 13:27 Сейчас в теме
(76)
я не просил объяснять это, я просил (риторически) сказать, в чем заключается ваша "ответственность", из-за которой ушей не видно

Опять двадцать пять... Что такое "мокрое"? Пока не попробуешь, не поймешь, чем оно отличается от сухого. Попробуйте взять на себя ответственность за свою работу, за свою жизнь, за свои решения, поймете. Хотя, даже если сейчас и не поймете, с возрастом все равно придет.
89. tango 506 16.03.11 15:23 Сейчас в теме
(84) Я уже понял, что так называемые "ответственные товарищи" просто принимают за ответственность ощущение собственной значительности. Понимание, что идиома "за базар ответишь" - в некоторых ситуациях не просто слова, приходит не не с возрастом, а с жизненным опытом.
211. warden 101 17.03.11 22:04 Сейчас в теме
(89) Четвертый пост от Вас, и ничего кроме критики нет. А что-то по существу есть сказать? И упорно скатываетесь к "за базар ответишь"... Впрочем, Ваша жизнь, Вам решать.
Я говорю о способности взять на себя ответственность, без которой немыслимо заниматься управлением. А не о том, в чем эта ответственность будет заключаться в конкретном случае.
94. 16.03.11 16:36 Сейчас в теме
(65)(68)(76)(84) о материальном выражении ответственности и о том что такое ошибки и кому они по силам а кому нет...
Расшифрую...
Не так давно взял на себя проект по 1С. Получил аванс.
В ходе проекта выяснился ряд нюансов которые не учел. Попытался все же решить проблемы за свой счет без напрягания мозга заказчику.
Убил пол года времени. Сделал проект на половину, т.е. оборудование и программа стоит, но обещанных функций не выполняет и нужную информацию не дает, хотя с виду все красиво. В моем понимании проект на половине это ноль.
Вернул все деньги заказчику обратно, все купленное оборудование отдал ему в подарок в качестве извинения за потраченное время.

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

Есть и другие примеры, когда проект провален, но причина то размыта... где то заказчик не сумел принять решение, где то побоялся, где то постеснялся, где то просто начал замыливать вопросы... проект провален... но брать эту ответственность на себя - мало приятного. Хотя и такое может быть.

Или тебе хочется чтобы руководителей именно расстреливали за ошибки? Если ты не в курсе то так думают только рядовые специалисты... любой успешный человек, который решал задачи чуть сложнее программирования и который хоть чего то в этой жизни добился, скажет тебе что все это достигается лишь ценой ошибок. Не ошибается тот кто ничего не делает (с) народная мудрость.
71. Арчибальд 2706 16.03.11 11:38 Сейчас в теме
Необходимо также четко осознавать границы нашей ответственности. Если при обсуждении с заказчиком оказывается, что он не ухватывает существенные моменты задачи, помните, что наша личная, поставленная нами самими цель - найти наилучший ответ - не обязательно означает заставить заказчика принять один лишь этот ответ. Любое размышление, которое допускает одну стратегию, обычно допускает несколько других стратегий, каждая из которых имеет свои достоинства и недостатки. Это всегда можно обобщить и получить удовлетворение от хорошо проделанной работы по изучению возможностей и обоснования своего выбора заказчику. Если, при полном понимании, заказчик делает выбор, который вам кажется глупым, то каким еще способом организация заказчика может чему-то научиться?

Вы не должны спасать весь мир, только свой небольшой кусочек и еще чуть-чуть, если сможете!

© Alan Carter The Programmers' Stone (Программистский камень)
75. Арчибальд 2706 16.03.11 12:22 Сейчас в теме
Цель этой работы - донести элементы "опыта" или "взглядов", на которые повсеместно ссылаются, но редко описывают. Многие темы - это то, что программисты обсуждают за пивом. Кажется странным, что никто не стремится узнать, как проблемы, которые программисты считают наиболее важными, соотносятся с "формальными" структурами современной инженерии.
© Alan Carter The Programmers' Stone (Программистский камень)

Первая из обсуждаемых статей относится как раз к "формальным структурам". Это дает автору право на фразу "Ключевая проблема в том что внедрением занимаются программисты. Хотя это задача управленческая." Другими словами, программист без управленческих навыков завалит проект (хотя программистов без управленческих навыков не бывает, но навыки могут оказаться недостаточными).

Вторая статья (эта) касается проблем, "которые программисты считают наиболее важными". В основном - проблема постановки задачи, которой просто не существует при типовых внедрениях. Там задача поставлена изначально и корректировке не подлежит. А тут речь идет о том, что из менеджеров (как правило) постановщики задач никакие, а программист (не кодер, конечно, а втоматизатор) - это прирожденный постановщик задач. Кстати, за пивом это обсуждают программисты, которых по объективным или субъективным причинам к постановке задач не подпускают.

Статьи, таким образом, относятся просто к разным сферам деятельности. Первая - как организовать работу конвейера по сборке "Жигулей". Вторая - кто может собрать реальный автомобиль из запчастей к "Жигулям".
sheykin; WanGoff; krv2k; Anything; vkr; Spartan; tango; +7 Ответить
77. tango 506 16.03.11 12:28 Сейчас в теме
(75) я с шестерки двигатель снимал в одиночку. разобрал, собрал и поехал :)
85. Spartan 365 16.03.11 13:54 Сейчас в теме
(75) В точку. Именно об этом я и пытался сказать в (36). Авторы спорят о разных вещах...
79. Арчибальд 2706 16.03.11 12:29 Сейчас в теме
И еще одна цитата http://ailev.livejournal.com/470473.html
Конечно, не всем людям нужно уметь записывать и обсуждать планы-расписания, предназначенные для выполнения теми или иными организациями, отнюдь не всем людям нужно обеспечивать железную логику в своих высказываниях. Но всегда есть профессии (например, профессия администратора в ее самых разных ипостасях - государственного бюрократа, проектного менеджера, производственного диспетчера и т.д.), в которых программистское мышление может быть более ценным, нежели в случаях других профессий.
86. venger 2121 16.03.11 14:09 Сейчас в теме
Если так случилось, что руководитель проекта не программист, то все просто - он должен организовать "кофе, чай и бутерброды" программистам, а дальше все зависит от них (как всегда), смогли самоорганизоваться, выбрать из своего круга "теневого" руководителя и выполнить работу - молодцы, нет - значит, можно сказать, что руководитель не программист, не профессионал, в этом все дело, и дальше продолжать любить себя;-) Программисты всегда в выигрыше, в общем;-)
88. dabu-dabu 289 16.03.11 15:03 Сейчас в теме
Обе статьи по большому счету - верные, просто для разных ситуаций.

Профессия "менеджер" (Руководитель проекта) не только есть, но является чуть-ли не центральным звеном в любой деловой деятельности.

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

На мелком проекте - должности руководителя, ведущего специалиста, программиста, консультанта обычно объединяются в одном человеке и это абсолютно оправдано. При этом он должен быть прежде всего программистом-консультантом, т.к. управлять ему все равно по большому счету некем.
На среднем проекте - обычно должности руководителя, ведущего специалиста - один человек.
На крупном проекте - руководить должен заниматься только руководством и не чем больше.
Нельзя одновременно быть и отличным программистом (консультантом) и отличным руководителем. А на крупных проектах руководитель должен быть только отличным. От руководителя в основном и зависит удачное завершение крупного проекта.
sheykin; WanGoff; imxored; krv2k; Anything; Арчибальд; +6 Ответить
90. tango 506 16.03.11 15:27 Сейчас в теме
(88) может быть, вы попробуете раскрыть п.1, первая часть?
92. dabu-dabu 289 16.03.11 16:15 Сейчас в теме
(90)
tango пишет:

(88) может быть, вы попробуете раскрыть п.1, первая часть?

По поводу ответственности? Попробую (очень кратко):
Что такое руководящая должность - это прежде всего полномочия, с помощью которых может быть выполнена некоторая деятельность. Полномочия делегируются тем, кто над руководителем проекта (директор, рук. отдела, рук. направления и т.п.). Но вместе с полномочиями всегда должна идти и ответственность. Если есть какой-либо перекос в полномочиях-ответственности, то руководитель скорее всего или не сможет выполнить поставленные перед ним задачи, или не захочет их выполнять.
В чем выражается ответственность? Чаще всего в том же, что и для многих других должностей - "пряник-кнут":
- Премии
- Повышения (или более интересные-крупные-прибыльные проекты)
- Увольнение
- Плохие / хорошие характеристики (известность) и т.п.
Просто если программист несет ответственность за написанный им функционал, то руководитель - за проект в целом. Разница есть? Если не чувствуете, то чем-то более-менее крупным не руководили.
PS в основном разница в объеме ресурсов (человеческих, финансовых, временных), которые затрачиваются на ту работу, за которую ты отвечаешь. Когда видишь, какое количество людей (в том числе важных тебе людей) зависят от твоей работы. Это и программисты-консультанты; это и сотрудники Заказчика. Одна моральная ответственность чего стоит.
Ilyabaykov; +1 Ответить
96. tango 506 16.03.11 17:12 Сейчас в теме
(92)
- Премии
- Повышения (или более интересные-крупные-прибыльные проекты)
- Увольнение
- Плохие / хорошие характеристики (известность) и т.п.

Это чисто зарплатная мотивация, от которой вы легко перепрыгнули (даже не заметив пропасти) к

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

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

(94) Или тебе хочется...
Как однако любите вы переходить на личность.
Хочется мне, пожалуй, чтобы на ИС было поменьше необоснованных утверждений.

Тема была - почему валятся проекты. Вы прекрасно ответили: "выяснился ряд нюансов которые не учел"
Утешаю: не вы один. У всех этих проектов есть общая черта - демпинг со стороны РП.
А вот вернуть аванс и отдать, что купил, в данном случае как пример ответственности не принимается:
во-первых, все обстоятельства вы тут все равно не расскажете;
во-вторых, это, возможно, был самый дешевый вариант;
в-третьих, я полагаю, что вы не идете на каждый проект, с намерением все и даже больше вернуть, если не получится. и уж тем более я уверен, что эта конкретная "ответственность" вами в договоре не прописывается.
И вы ничего не сказали об ответственности перед своими сотрудниками.
105. dabu-dabu 289 16.03.11 23:21 Сейчас в теме
(96) Так в том-то и дело, что никакой принципиально "особой ответственности" нет по сравнению с любыми другими профессиями нет, но есть 2 фактора:
1. возлагается на РП гораздо больше чем, допустим, на программиста. Как я уже говорил, объем ресурсов и значимость целей, фактически доверенных РП, достаточно велик по сравнению со многими другими профессиями.
2. при провале проекта, может серьезно подорваться востребованность РП, в том числе и у других потенциальных работодателей. Т.к. в этой среде (если РП крупный) предоставляется работа в основном только по знакомству.
Принципиально иная ответственность у бизнесменов. А у всех наемных работников, по большому счету, одно и тоже, что я и пытался написать в том сообщении, но, видимо, не донес.

То что я с "материальной" ответственности перескочил на моральную - так я трактат с плавными переходами писать и не собирался. А о моральной собственно написал только как важной для меня. У кого-то моральная ответственность выше, у кого-то ниже, у иных вообще нет. Все зависит от человека.
107. tango 506 17.03.11 07:54 Сейчас в теме
(105) программер из команды грохнуть может ту же самую базу, что и его РП
Востребованность - это опять таки мотивация из разряда зарплатных. Я же оспроривал "ответственность", преподносимую как нечто функционально, "ролево" (?) отличающее РП от члена команды. И показывал, что это - всего лишь самомнение.
То, что "особо крупные" РП - штучный товар, это во всех отраслях так. Я уже упоминал чубаса - провалил, гад, все, где пометился, и ничего. Связи,понимаешь. Ответственность - в терминах оппонента...
(106) а плюсь? :D
111. dabu-dabu 289 17.03.11 10:05 Сейчас в теме
(107)грохнуть базу может и уборщица неудачно вылив воду на сервер :). Ну и что дальше, что вы этим хотели сказать?
РП отличает от других членов команды только то, что он руководит остальными членами команды и отвечает за результат работы всей команды перед работодателем. И больше ничего.
То что многие упирают на "особую ответственность", видимо они имели ввиду, что ответственность крайне важна на любой руководящей должности. Это один из центральных факторов работы руководителя. Как я уже писал полномочия-ответственность, это то что определяет важность руководителя и, соответственно, его "зарплату".
А возможно путаница из-за того, что многие совмещают РП и бизнесмена, которому заказывают реализацию проекта. В общем случае это совсем разные люди. И не в коем случае не стоит эти должности путать. Но при этом, да, во многих случаях они совмещаются в одном человеке.


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