gifts2017

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

Опубликовал Борис Балясников (bb1962) в раздел Управление - Управление проектом

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

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

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

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

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

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

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

А комментарии как раз и нужны, что понять, кто за и против. Тем более в комментариях к той статье тоже развернулось немаленькое обсуждение.
15. Александр Рытов (Арчибальд) 15.03.11 11:03
(12)
Статья моего оппонента не дискуссионная, это не призыв к обсуждению, это
УТВЕРЖДЕНИЕ.
Но обсуждение из 138 постов все же случилось ;)
(13) Компьютер должен работать, а человек - думать.
16. Михаил Ражиков (tango) 15.03.11 11:11
(6) есть, есть, мое предпоследнее место работы - БТК: крутецкий оптовик всего, что втыкается в розетку, не менее двух лет БиТ сосал бабло, УТ+Инталев, в результате одного ключевого пользователя (продажника) уволили, другой (финдир) в конце проекта писал "все проводки неправильные", прогнали битовцев, уволили всех. кого брали на подхват. начали сокращать своих штатных 1снегов, завели речи о возврате на 7.7
руководитель от БиТа "Кирилл Гусев":mailto:kgusev@1cbit.ru
17. Михаил Ражиков (tango) 15.03.11 11:13
18. Михаил Ражиков (tango) 15.03.11 11:24
+(16) форма расходного ордера на определенную выплату содержала пять (пять!) разных реквизитов, которые должен был заполнить оператор, чтобы указать системе, что это ордер именно на такого рода определенную выплату
19. Александр Рытов (Арчибальд) 15.03.11 11:31
20. Ийон Тихий (cool.vlad4) 15.03.11 11:49
вывод-то в итоге какой? надо работать? ..ли...
21. Александр Рытов (Арчибальд) 15.03.11 11:57
22. Борис Балясников (bb1962) 15.03.11 12:15
(20) Надо. В том числе надо "работать" с теми, кто мешает.
С теми, кто занимает чужое место, кто присваивает
себе кем то заработанное. Это уже отдает политикой, но без этого никак.
23. vkr (vkr) 15.03.11 12:25
+512 !!!

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

Брукс - профессор вычислительной техники, известен, прежде всего, как "отец IBM System/360" (кто знает - поймет :) ).
В США полагают, что без прочтения книги Брукса не может состояться ни один руководитель программного проекта.
---
А если взять нашу, российскую реальность, то, ес-сно, когда босс ни черта не понимает в разработке,
ориентирован только на зарабатывание "буказоидов", и при слове "ТЗ" впадает в ступор, то можно легко представить
итоговое качество и сроки проекта... :)
Еще раз - ОГРОМНОЕ СПАСИБО автору !!!
Yakud3a; zinch; Rustig; +3 Ответить 2
24. г. Казань Рустем Гумеров (Rustig) 15.03.11 12:30
25. Ийон Тихий (cool.vlad4) 15.03.11 12:49
Прикрепленные файлы:
mithsoftware.rar
fomix; sergeevcorp; Rustig; Alraune; +4 Ответить 2
26. Борис Балясников (bb1962) 15.03.11 12:56
(24)(25) Может быть все-таки почаще в отладчике тексты читать?
27. Александр Рытов (Арчибальд) 15.03.11 13:06
(23) (24) (25) На Инфостарте есть все
http://infostart.ru/public/72612/ ;)
cool.vlad4; +1 Ответить 1
28. Ийон Тихий (cool.vlad4) 15.03.11 13:14
(26)?
Прикрепленные файлы:
29. vkr (vkr) 15.03.11 13:52
(27) Лучше уж тогда - с картинками :), вот отсюда :
"Мифический человеко-месяц..." (в формате PDF, 1.5Мб)
30. Александр Рытов (Арчибальд) 15.03.11 14:07
(29) У меня именно с картинками. Из юбилейного издания 95 года
31. Ийон Тихий (cool.vlad4) 15.03.11 14:21
(29) на либрусеке вообще-то с картинками ...добавлять некогда было в архив...
32. Ирина Пятакова (Alraune) 15.03.11 14:36
(31) С картинками, да. Сейчас сижу, читаю. Спасибо за ссылку)))
33. Михаил Ражиков (tango) 15.03.11 14:56
из Брукса, в поддержку (0) :
"Вывод прост: если над проектом работают 200 человек, включая менеджеров, являющихся наиболее знающими и опытными программистами, увольте 175 бойцов, и пусть менеджеры снова займутся программированием."
YVolohov; +1 Ответить
34. A.Y 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 Ответить 3
35. Anatolii Karasev (KapasMordorov) 15.03.11 15:34
(34)
Программист, консультант - да какая разница? Они ж ресурсы.
Вот из небрежностей (сырых дровишек) и любых РП и получается провал.

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

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

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

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

Если на проекте больше одного исполнителя, то нужен руководитель. Выделять отдельного человека на руководство не всегда целесообразно. Совместительство требуется в большинстве случаев.
cool.vlad4; Spartan; +2 Ответить 1
44. Василий Казьмин (awk) 15.03.11 18:12
(43) Это не руководитель - это координатор. Не надо теплое с мягким путать. Координатором и секретарь может быть.
45. A.Y 15.03.11 18:14
(41) Арчибальд, ну не мне тебе рассказывать, что уж если выводить правила, то такие которые помогают в большинстве ситуаций.
И если внедрять 1С Бухгалтерию 8 или 1С ЗУП 8, то в большинстве ситуаций типовой функционал достаточен для запуска системы и выполнения первостепенных функций, для основных целей - экономия затрат, снижение ошибок, получение базовой информации и отчетов. Все остальное второстепенно и может ждать, потому выносится за проект.

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

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

И если человек которого волею судьбы поставили ответственным за сложную задачу - создать информационную систему, будет искать подсказку, то что ему поможет? Эта опозиционная отрыжка в виде попытки назвать руководителей бесполезными людьми или моя статья которая дает конкретные подсказки?
Anything; Spartan; +2 Ответить 1
46. Трактор Трактор (Трактор) 15.03.11 18:19
(44) Руководитель тот кто несёт ответственность за деятельность бригады, команды, группы, отдела. Если он при этом совмещает руководство с производственной деятельностью, то это руководитель по совместительству. А так получается что ты просто не признаёшь существование совместительства.
47. A.Y 15.03.11 18:32
Ответственность штука сложная. На много сложнее взять на себя ответственность и выполнить обязательства любой ценой.
Гораздо проще мнить себя пупом земли, выполнять свои должностные инструкции, и дальше мониторов не заглядывать.
А управление это способность достигать результатов. Что для этого нужно? Да все!
Надо - глав.буха соблазнишь, надо - столы потаскаешь, в гостиницах без отопления поспишь, в самолетах полетаешь без передышки неделю, выслушаешь какой ты козел от 8 из 10 сотрудников, пару ночей без сна перебьешься перед закрытием проекта...
И все эти особенности как правило знают лишь те кому приходилось нюхать такое слово как ответственность, чтобы зарплату получали те кто кроме программирования в этой жизни ничего не хочет.
48. Ийон Тихий (cool.vlad4) 15.03.11 18:36
"Наилучший руководитель - тот, о котором люди знают только, что он существует. Когда его работа выполнена, они скажут: ‘Мы сделали это сами’". ( Лао Цзы)
49. Василий Казьмин (awk) 15.03.11 18:43
(46) Более того я не только его признаю, но и описываю ситуации возникновения данного явления. Один из которых - это простота проекта, при которой исполнитель может попеременно исполнять разные роли. Половина людей на этом сайте приходя к клиенту играют роль менеджера по продажам, сев за компьютер - руководителя, технического писателя, программиста, тестировщика (роль о которой все забыли), а вернувшись к клиенту с результатами - роль внедренца. Дальше больше - они начинают играть роль тех. поддержки.

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

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

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

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

И если участники все заняты своими делами, тогда приступаю к выполнению сам, беру как правило те задачи, которые не потянуть не программистам, не консультантам. Это или конфликты или политика или улаживание противоречий между различными сторонами. Ну а когда время освобождается на старое и доброе программирование так что получается уйти в него с головой и не думать о течении проектов, ну это почти что праздник души ))
57. A.Y 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 пользователей... то там скулы трещат по швам и на пару лет приходится забыть про личную жизнь.

Сунь туда своего сервис-инженера или программистов-фанатиков (которых хлебом не корми дай попрограммировать) без компетенций по управлению и посмотри что станет с проектом.
Сервис инженер загнется после первого же конфликта сторон, проргаммист не сумеет выдержать рамок, начнет изменять программу и проект начнет растекаться как понос. К дате окончания контракта выяснится что результатов нет и система в состоянии не стояния - хотя вроде программировали днями и ночами.
58. A.Y 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
59. Александр Рытов (Арчибальд) 16.03.11 07:47
(45) А я, собственно, и не возражаю. Не бывает универсальных рецептов. И те два подхода, в 41 посте, я не противопоставлял, а сопоставлял. В реальности они вряд ли встречаются "в чистом виде". Если автоматизация начинается "с нуля", от арифмометров - первый подход должен превалировать. И совершенно другая ситуация, когда предстоит переход от ПУБ к КА. Там с большой вероятностью продуктивнее будет второй вариант.
60. Михаил Ражиков (tango) 16.03.11 09:22
общепризнанные = признанные мной - позиция ожидаемая.

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

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

**
минус в (57) - за голимую саморекламу
61. Александр Рытов (Арчибальд) 16.03.11 09:32
(60) А нужен ли архитектор при строительстве хрущоб? Там прораба достаточно.
62. vkr (vkr) 16.03.11 09:41
(61) Присоединяюсь!
А нужно ли вообще строить хрущобы ?
Может, немного подумать головой и построить что-то получше - где и архитектор нужен ? :)
63. warden 16.03.11 09:44
Написано разумно. Единственное, есть непонимание некоторых нюансов. Они не столь банальны, так что это простительно.
не надо организованность и дисциплину выдавать за отдельную профессию. Руководитель проекта - это не профессия, это скорее должность

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

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

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

Напоминает старый анекдот "х...ню мы не лечим, а п....ц неизлечим". Вам ведь не надо напоминать про квалификацию врача, сказавшего эти слова? Открою секрет - нормальные, грамотные руководства пользователей - существуют. Их можно и здесь найти. Если только! - задаться вопросом "а поймут ли вас пользователи?" К сожалению, пока я вижу, что этим вопросом Вы даже не планируете задаваться.
К слову, сам я программист. Повидал и хороших и плохих руководителей. И хороших и плохих программистов. Экзистенциальная позиция автора мне тоже знакома хорошо, а ИТ среде это, к сожалению, не редкость. Впрочем, специфика профессии такова.
Anything; Трактор; +2 Ответить 1
64. Михаил Ражиков (tango) 16.03.11 09:46
(61),(62)
tango пишет:
разумеется, что речь не идет о "типовых" внедрениях


пример "эффективного менеджера" : чубайс - авария в СШ, цены на энергию
65. Михаил Ражиков (tango) 16.03.11 09:50
(63) и другие:
Что значит "взять на себя ответственность"

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

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

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

конкретно, в чем заключалась ваша ответственность как РП, во-первых, перед подчиненными, во-вторых, перед заказчиком.
конкретно - ваша, и конкретно - сколько
ну, т.е, ваши подчиненные знали, что если проект провалится, вы ответите конкретной суммой денег?
66. vkr (vkr) 16.03.11 09:50
(58) К Вашему пункту 2 ("Стадии роста...") :
6. Просветление. Прошедши сквозь стадии 1-5, и поняв, что более заняться нечем,
начинает блогосферную деятельность...
Sorry. "it was just business, not personal"
67. warden 16.03.11 10:09
(65) "Взять ответственность" - вот тут как раз пока не "возьмешь", не поймешь :D И обьяснить невозможно.
Те, кто реально руководит, организует, а не сидит на должности, поймут. И еще те, кто занялся своим бизнесом. Остальным могу сказать только - попробуйте.
Вот описать типичные проблемы при этом - это пожалуйста - кто-то не знает "как делать", кто-то не знает "что делать", в смысле куда двигаться. В результате как раз и мало людей, способных это сделать.

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

ну, я так понял, что ответственность ваша носит некий нематериальный характер.
собственно, это и есть и причина развала союза, и провалов 1сных проектов
69. Василий Казьмин (awk) 16.03.11 11:08
(60) Архитектор и руководитель - это разные роли. Одна роль отвечает на вопрос: "Как может быть?", а вторая: "Как это будет достигнуто?". В одном человеке роли совпадают до тех пор, пока проект мал (или мало проектов).
70. Михаил Ражиков (tango) 16.03.11 11:29
(69) стройка. есть архитектор (Как может быть). есть прораб (Как это будет достигнуто). Вы не путаете производителя работ с руководителем проекта?
Королев - что бы сделал, не будь инженером?
И еще раз - чубас - ...
71. Александр Рытов (Арчибальд) 16.03.11 11:38
Необходимо также четко осознавать границы нашей ответственности. Если при обсуждении с заказчиком оказывается, что он не ухватывает существенные моменты задачи, помните, что наша личная, поставленная нами самими цель - найти наилучший ответ - не обязательно означает заставить заказчика принять один лишь этот ответ. Любое размышление, которое допускает одну стратегию, обычно допускает несколько других стратегий, каждая из которых имеет свои достоинства и недостатки. Это всегда можно обобщить и получить удовлетворение от хорошо проделанной работы по изучению возможностей и обоснования своего выбора заказчику. Если, при полном понимании, заказчик делает выбор, который вам кажется глупым, то каким еще способом организация заказчика может чему-то научиться?

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

© Alan Carter The Programmers' Stone (Программистский камень)
72. warden 16.03.11 11:41
tango пишет:
(67) "И обьяснить невозможно." vs"профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот"

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

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

Я, может быть, не очень четко указал центральный посыл своей идеи - я, в противоположность автору статьи, считаю, что руководитель проекта не обязательно должен быть хорошим программистом, а вот хорошим руководителем он должен быть обязательно. Обосную - грамотный руководитель может плохих исполнителей и поменять, а вот при плохом руководителе и хорошие сотрудники могут каши не сварить. Подчеркну - "может" не значит "будет". Просто шанс успешного доведения проекта на порядок выше.
Сразу могу ответить на первое возражение: "а как он разберется, где хороший программист, а где нет?". Ответ: сам - никак. Но на моей памяти хорошие управленцы всегда имеют множество хороших знакомых специалистов в самых разных областях, и в том числе в ИТ сфере, способных верно оценить потенциал сотрудника. И не припомню ни одного случая, когда бы хороший управленец принял на работу плохого программиста. Больше того, куча примеров, когда толковый начальник ИТ отдела вообще в 1С не шарил ну просто никак, при этом никаких проблем в этой сфере не было, все решалось очень быстро и эффективно.
73. Василий Казьмин (awk) 16.03.11 11:51
(70) Давайте подытожим роли:

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


Я забыл наверняка что-нибудь - подправьте если не сложно.
74. vkr (vkr) 16.03.11 12:19
(73) 1. Заказчик - ЧТО (в первую очередь!) / Зачем (цель проекта) / Когда (сроки) / Почём...
2. Руководитель проекта - Что / Зачем (цель проекта) / Кто (коллектив) / Когда / Почём
3. Архитектор - Что (вдаваясь в детали!) / Зачем / Когда / На чём
75. Александр Рытов (Арчибальд) 16.03.11 12:22
Цель этой работы - донести элементы "опыта" или "взглядов", на которые повсеместно ссылаются, но редко описывают. Многие темы - это то, что программисты обсуждают за пивом. Кажется странным, что никто не стремится узнать, как проблемы, которые программисты считают наиболее важными, соотносятся с "формальными" структурами современной инженерии.
© Alan Carter The Programmers' Stone (Программистский камень)

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

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

Статьи, таким образом, относятся просто к разным сферам деятельности. Первая - как организовать работу конвейера по сборке "Жигулей". Вторая - кто может собрать реальный автомобиль из запчастей к "Жигулям".
sheykin; WanGoff; krv2k; Anything; vkr; Spartan; tango; +7 Ответить 2
76. Михаил Ражиков (tango) 16.03.11 12:24
(72) еще одна характерная примета: "вот обьяснить Вам, что значит "управлять""

я не просил объяснять это, я просил (риторически) сказать, в чем заключается ваша "ответственность", из-за которой ушей не видно.
77. Михаил Ражиков (tango) 16.03.11 12:28
(75) я с шестерки двигатель снимал в одиночку. разобрал, собрал и поехал :)
78. Василий Казьмин (awk) 16.03.11 12:28
(74) Заблуждаетесь. Заказчик никогда не знает что ему нужно, в какие сроки это будет сделано, какова себестоимость. Он может ответить только на вопрос сколько он готов заплатить и кому.
79. Александр Рытов (Арчибальд) 16.03.11 12:29
И еще одна цитата http://ailev.livejournal.com/470473.html
Конечно, не всем людям нужно уметь записывать и обсуждать планы-расписания, предназначенные для выполнения теми или иными организациями, отнюдь не всем людям нужно обеспечивать железную логику в своих высказываниях. Но всегда есть профессии (например, профессия администратора в ее самых разных ипостасях - государственного бюрократа, проектного менеджера, производственного диспетчера и т.д.), в которых программистское мышление может быть более ценным, нежели в случаях других профессий.
80. Михаил Ражиков (tango) 16.03.11 12:30
+(78) ... кому конкретно. тендер, понимаешь
81. Василий Казьмин (awk) 16.03.11 12:40
(80) Забыл в (73) роль "Менеджер по продажам (Как объяснить клиенту, что это надо делать за N$ период Т и в конторе "Рога и копыта" :))" - позор на мои седые волосы...
82. vkr (vkr) 16.03.11 12:47
(78) Я, конечно понимаю смысл Вашего возражения - в контексте книжек типа "Физики шутят"... :)
Но ведь, по большому счету, нормальный заказчик знает - ЧТО он хочет получить (eg, систему учета "Рога и копыта"),
срок и примерную сумму, за которые он хочет это получить. А уж на сколько его попытаются развести - бог знает...
Наверное, если руководитель проекта - из программеров, то заказчику будет легче... В России, по крайней мере... :)
83. Василий Казьмин (awk) 16.03.11 13:07
(82) Не так... Заказчик обращается к автоматизатору по двум причинам:

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

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

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

Опять двадцать пять... Что такое "мокрое"? Пока не попробуешь, не поймешь, чем оно отличается от сухого. Попробуйте взять на себя ответственность за свою работу, за свою жизнь, за свои решения, поймете. Хотя, даже если сейчас и не поймете, с возрастом все равно придет.
85. Иван (Spartan) 16.03.11 13:54
(75) В точку. Именно об этом я и пытался сказать в (36). Авторы спорят о разных вещах...
86. Александр Венгер (venger) 16.03.11 14:09
Если так случилось, что руководитель проекта не программист, то все просто - он должен организовать "кофе, чай и бутерброды" программистам, а дальше все зависит от них (как всегда), смогли самоорганизоваться, выбрать из своего круга "теневого" руководителя и выполнить работу - молодцы, нет - значит, можно сказать, что руководитель не программист, не профессионал, в этом все дело, и дальше продолжать любить себя;-) Программисты всегда в выигрыше, в общем;-)
87. vkr (vkr) 16.03.11 14:49
(83) По первому пункту - согласен. По второму - нет.
Клиент может прекрасно знать - В ЧЕМ у него проблема (авто не едет, костюмчик жмет, система не так считает),
но решить ее САМ (как Вы правильно отметили) не в состоянии - попросту в силу того, что не умеет этого сделать...
Вы же сами не управляете самолетом, когда летите в отпуск на Канары :), хотя можете в тонкостях разбираться
в теории аэродинамики...
Но, наверное, наша дискуссия уже ушла от темы...
88. Mahavishnu (dabu-dabu) 16.03.11 15:03
Обе статьи по большому счету - верные, просто для разных ситуаций.

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

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

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

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

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

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

А недавно был реализаван мелкий проект, но там было более одного человека задействовано и руководитель отдельный был (1С + PHP + C#).
94. A.Y 16.03.11 16:36
(65)(68)(76)(84) о материальном выражении ответственности и о том что такое ошибки и кому они по силам а кому нет...
Расшифрую...
Не так давно взял на себя проект по 1С. Получил аванс.
В ходе проекта выяснился ряд нюансов которые не учел. Попытался все же решить проблемы за свой счет без напрягания мозга заказчику.
Убил пол года времени. Сделал проект на половину, т.е. оборудование и программа стоит, но обещанных функций не выполняет и нужную информацию не дает, хотя с виду все красиво. В моем понимании проект на половине это ноль.
Вернул все деньги заказчику обратно, все купленное оборудование отдал ему в подарок в качестве извинения за потраченное время.

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

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

Или тебе хочется чтобы руководителей именно расстреливали за ошибки? Если ты не в курсе то так думают только рядовые специалисты... любой успешный человек, который решал задачи чуть сложнее программирования и который хоть чего то в этой жизни добился, скажет тебе что все это достигается лишь ценой ошибок. Не ошибается тот кто ничего не делает (с) народная мудрость.
95. Mahavishnu (dabu-dabu) 16.03.11 16:52
[URL=http://forum.infostart.ru/redirect.php?url=L2FqYXgvc2hvd19jb21tZW50LnBocD90PTM4NTcwJmFtcDtjPTkz](93) Деление на мелкий-средний-крупный я привел достаточно условно.
При определении необходимости в отдельном руководителе необходимо ответить на следующие вопросы:
1. Сколько людей участвует на проекте, как со стороны Заказчика, так и со стороны Исполнителя?
2. Каков объем ожидаемых проблем (зависит от сложности учета, сложности требований, адекватности руководителей Заказчика, необходимости автоматизации для конечных пользователей, опыта реализации подобных проектов)?
3. Какой объем проблем может потянуть Руководитель?
Т.е. по большому счету все познается на опыте.
А так, если необходимо хотя-бы 5 программистов и проект более чем на два месяца, то уже необходимо серьезно задумываться о выделении руководителя - ведущего специалиста. При этом, обычное дело, когда есть отдельный руководитель, который ведет несколько некрупных проектов.

PS Из слов "зелен и жаден я был" могу сделать предположение, что вы и "предприниматель", правда, который сам пытается сделать всю работу.
Так могу сказать, что это что угодно, но только не бизнес. Человеку, строящему свой бизнес не в коем случае нельзя спускаться до выполнения конкретной работы. Он должен решать только вопросы найма сотрудников с делегированием полномочий, развивать бизнес, выбирать направления деятельности, искать где бы взять денег или еще Клиентов и решать проблемы взаимодействия с государством. Предприниматель ни в коем случае не должен быть "жаден", он должен только решать проблемы эффективности. ИМХО
96. Михаил Ражиков (tango) 16.03.11 17:12
(92)
- Премии
- Повышения (или более интересные-крупные-прибыльные проекты)
- Увольнение
- Плохие / хорошие характеристики (известность) и т.п.

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

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

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

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

Тема была - почему валятся проекты. Вы прекрасно ответили: "выяснился ряд нюансов которые не учел"
Утешаю: не вы один. У всех этих проектов есть общая черта - демпинг со стороны РП.
А вот вернуть аванс и отдать, что купил, в данном случае как пример ответственности не принимается:
во-первых, все обстоятельства вы тут все равно не расскажете;
во-вторых, это, возможно, был самый дешевый вариант;
в-третьих, я полагаю, что вы не идете на каждый проект, с намерением все и даже больше вернуть, если не получится. и уж тем более я уверен, что эта конкретная "ответственность" вами в договоре не прописывается.
И вы ничего не сказали об ответственности перед своими сотрудниками.
97. A.Y 16.03.11 17:15
(92)(90) еще добавлю...
чем больше объем деятельности, тем больше знаний нужно для управления.
под управлением я понимаю просто способность получать результат. само собой ожидаемый.
скажем управлять написанием отчета об остатках на складе может и программист. знать нужно программу и особенности складского учета.
управлять проектом создания комплексной системы управления производством на предприятии в 500 человек сможет только человек знающий (умеющий) организовывать людей, видеть слабые стороны проекта, находить нужных людей или выполнять задачи самостоятельно.
управлять большими организациями или территориями сможет человек только зрелого типа, умеющий управлять эмоциями и отношениями, с хорошими связями, со способностью находить нужных людей на нужные места, принимать осознанные решения, чувствовать реальность.
итд.
уровень задачи, требует соответствующего уровня ответственности, что влечет за собой требуемый уровень знаний. под словом знание понимание не некие теоретические "я знаю, я читал", имеются ввиду глубокие знания, которые получаются только в результате практики.
98. A.Y 16.03.11 17:30
tango пишет:
Тема была - почему валятся проекты. Вы прекрасно ответили: "выяснился ряд нюансов которые не учел"

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

а теперь покажи где тут было сказано слово "проекты"? и зачем ты противоречишь своим же хотелкам? ))
я взял один проект, который был завален по этой причине. это не значит что это правило.
и взял я этот пример лишь чтобы показать тебе что такое ответственность.
если не дошло - проблемы не мои. извини.
99. desty (lustin) 16.03.11 17:44
awk пишет:

Позволю внести свои пять копеек:



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


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

для наведения порядка в голове советую:
0. Инженерия программного обеспечения
1. Брукс "Мифический человеко-месяц".
2. Иан Соммервилл "Инженерия программного обеспечения".
3. Рейнвотер "Как пасти котов".

При прочтении Вам советую особое внимание уделить вопросу моделей отношений руководителя к своим подчиненным.

P.S. А знаете кстати, что считается правильным подходом в случаях если отличный управленец по проектам, не обладает достаточным техническим знанием - изыскивается человек/ресурс у которого навыки программиста будут преобладать над управленческими в том же соотношении, что и менеджера навыки управления преобладают над программисткими: и этот подход работает отлично, поверьте.
Отличительной особенностью такого подхода в крупных конторах, является наличие CIO и его заместителя по технической части, причем заместитель чаще всего не является по совместительству еще и начальником какого-нибудь отдела ИТ департамента.
И кстати, этот самый техничиский заместитель может,чаще всего хочет, и еще и участвует в написании кода, прототипов и ВНИМАНИЕ еще и документации.
100. Михаил Ражиков (tango) 16.03.11 17:50
(98) да все с тобой было понятно еще по первой статье, вступи в единую росию и успокойся
100!
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа