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

27.11.14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+155 –2

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.

См. также

ИИ для аналитика 1С: как читать и править код без разработчика

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

Разбираем, как аналитик 1С может использовать ИИ, чтобы разобраться в чужой внешней обработке без документации, шаблонов и комментариев в коде. Показываем, как восстановить логику загрузчика и структуру входных данных, подготовить Excel-шаблоны с техническими именами полей и внести минимальные правки, не разрушив работу обработки. Объясняем, где заканчиваются возможности ИИ и требуется участие разработчика. А также рассказываем, как получать укрупненные сценарии тестирования с понятными шагами и ожидаемыми результатами, которые удобно использовать при приемке.

11.11.2026 235 0 olga_kolyukova 2

Почему тормозит 1С? Большое расследование

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

Пока технические специалисты борются со «щупальцами спрута» – плохими запросами, некачественным кодом и покупкой нового железа, – мы предлагаем найти «голову», из-за которой проблемы с производительностью 1С возникают системно. Разбираем истинные управленческие причины падения скорости, скрытые за отсутствием сильных экспертов и привычкой команды писать код без предварительной оценки бизнес-задач. Объясняем ИТ-руководителям, PM, CTO, CIO и CDTO, как распознать эти первопричины и выстроить процессы, чтобы перестать бесконечно лечить симптомы и решить проблему на корню.

06.11.2026 884 0 Velifer 14

Карта компетенций аналитика 1С

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

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

29.10.2026 267 0 EKabanova 0

5 дней на оценку гибких навыков команды

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

Оценка гибких навыков часто оказывается долгим и дорогостоящим процессом, поэтому мы рассказываем, как выстроить ее внутри компании так, чтобы она была понятной, автоматизированной и безопасной для сотрудников. Разбираем этапы проекта: от создания модели из 20 компетенций до выбора тестов, кейсов, интервью и оценки «360 градусов» с автоматизацией в «1С:Оценке персонала». Показываем, как команда из 15 человек прошла оценку за рабочую неделю, а на подведение результатов потребовалось еще пять дней. Объясняем, как полученные данные помогли улучшить подбор, сформировать кадровый резерв, точнее планировать обучение, сократить трудозатраты руководителей и снизить текучесть.

14.10.2026 308 0 user2100930 1

Сеньор за 3 года, а не за 10. Карьерный компас для 1С-разработчика: матрица компетенций + пошаговый план прокачки

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

Пять лет я был Middle и не понимал почему. Тогда разложил карьеру 1С-разработчика на шесть грейдов и описал, что и как прокачать на каждом. От Junior до Senior — три года, не десять. Делюсь системой: матрица компетенций, шаблоны IDP, чек-листы для performance review. Проведёте самооценку — увидите, каких навыков не хватает именно вам.

16.09.2026 2924 0 aidar_safin 55

Один руководитель продуктового и технологического развития: временный компромисс или новая управленческая норма?

Компетенции и навыки Продуктовый подход Бесплатно (free)

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

24.08.2026 429 0 user1982126 0

От кризиса компетенций к новой модели развития: взгляд тимлида и HR на будущее найма и обучения

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

Разбираем, почему привычная модель найма перестает работать и как компаниям выстраивать развитие специалистов в условиях дефицита кадров и новых ожиданий сотрудников. Показываем, как связка HR и тимлида помогает превращать новичков без проектного опыта в самостоятельных специалистов без перегрузок и потери качества. Объясняем, как сетка грейдов, ABC-классификация задач, индивидуальные планы развития и регулярная обратная связь делают рост прозрачным, помогают вовремя выявлять зоны развития и повышают мотивацию. Материал будет полезен тимлидам, HR-специалистам и руководителям IT-направлений, которые хотят сократить текучесть, сформировать кадровый резерв и не допустить кадрового голода в ближайшие годы.

17.08.2026 626 0 user2135145 3

Чем должна отличаться оценка результативности руководителя ИТ-проекта от оценки других членов команды

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

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

04.08.2026 767 0 user2136222 0

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. Alraune 1507 15.03.11 00:11 Сейчас в теме

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

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

35. KapasMordorov 418 15.03.11 15:34 Сейчас в теме

(34)
Программист, консультант - да какая разница? Они ж ресурсы.
Вот из небрежностей (сырых дровишек) и любых РП и получается провал.

- программист (специалист знакомый с программой, и тем как выглядят процессы при ее использовании, может привлекаться со стороны)
© A.Y.

39. 15.03.11 15:48 Сейчас в теме

(35) человек, дорогой, от куда ты взял эту мысль? подумай... в том что ты выделил в качестве цитаты этой мысли не было и быть не могло )
еще раз прошу не надо мусор из ваших голов приписывать к моим формулировкам.

40. KapasMordorov 418 15.03.11 16:15 Сейчас в теме

(39)
Почитал про Растам-ИТ, больше вопрос и замечаний не имею.

38. Spartan 366 15.03.11 15:37 Сейчас в теме

Пока писал свой пост, автор в (34) сам уже подтвердил мои предположения... :)

41. Арчибальд 2712 15.03.11 16:34 Сейчас в теме

(34) Ну вот, опять внедрение "TO BE". Особенно примечательно

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

И это при том, что отнюдь не доказано, что внедрение данной компоненты проекта (которую хотят изменить)в неизмененном виде улучшит какой-то важный показатель.
Конечно, методически это правильно: отдельно внедряем то, что у нас есть "AS IS", говоря заказчику, что это и есть для него "TO BE". А потом уже за отдельную плату подгоняем то, что внедрили, под реальные потребности бизнеса (не хотелки, а именно потребности). Это нормальная позиция аутсорсера. Хлеб его.
М же ближе другая позиция, хотя тоже двухэтапная. Реальное проектирование системы с необходимыми отклонениями/добавками от того, что есть на рынке, включая отделение потребностей от хотелок, и создание этой системы (доведение функционала до потребностей бизнеса). Менеджер-непрограммист на этом этапе, скорее, навредит, чем поможет. Второй этап, внедрение, гораздо менее интересен с позиции творчества, и тут уж в самом деле программисты нужны только на исправление ошибок.

45. 15.03.11 18:14 Сейчас в теме

(41) Арчибальд, ну не мне тебе рассказывать, что уж если выводить правила, то такие которые помогают в большинстве ситуаций.
И если внедрять 1С Бухгалтерию 8 или 1С ЗУП 8, то в большинстве ситуаций типовой функционал достаточен для запуска системы и выполнения первостепенных функций, для основных целей - экономия затрат, снижение ошибок, получение базовой информации и отчетов. Все остальное второстепенно и может ждать, потому выносится за проект.

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

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

И если человек которого волею судьбы поставили ответственным за сложную задачу - создать информационную систему, будет искать подсказку, то что ему поможет? Эта опозиционная отрыжка в виде попытки назвать руководителей бесполезными людьми или моя статья которая дает конкретные подсказки?

59. Арчибальд 2712 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 993 15.03.11 06:11 Сейчас в теме

Alraune пишет:
Вроде, одна статья не противоречит другой.

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

4. Арчибальд 2712 15.03.11 08:08 Сейчас в теме

Не удержусь от повторения своего же комментария к статье "4 ключевые..."

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

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

ОФФ. На заре моей автоматизаторской деятельности нас обязали еженедельно планировать и учитывать рабочее время. И старый мудрый начлаб посоветовал мне отводить 60-80 процентов времени на ликвидацию последствий вмешательства высокого начальства - в современной терминологии, руководителя проекта.
Прилагаю аватарку для статьи :)

Прикрепленные файлы:

Ответить

5. bb1962 993 15.03.11 09:46 Сейчас в теме

Арчибальд пишет:
Может ли проект, возглавляемый менеджером, быть успешным?

Еще не факт, что в описанной ситуации ведущий программист захочет брать на себя
обязанности руководителя проекта и тащить на себе целую гирлянду спиногрызов.
Так что ТОЛЬКО увеличение стоимости проекта - это в лучшем случае.

6. RustIG 1990 15.03.11 09:51 Сейчас в теме

У кого-нибудь есть примеры проектов, в которых РП не "из программистов"?
Мне пока не ясно - актуален ли данный "разбор полетов"?

7. bb1962 993 15.03.11 10:04 Сейчас в теме

(6)
Судя по количеству плюсов, которые получила статья http://infostart.ru/public/71671/,
таких примеров предостаточно.
Я так понимаю, что каждый проголосовавший согласен с доводами автора этой статьи.

8. Арчибальд 2712 15.03.11 10:25 Сейчас в теме

(7) Не так. Я тоже поставил плюс за ту статью, однако как рекомендацию к прочтению/размышлению, а не как согласие с содержанием. Мне ближе позиция этой статьи, и именно в том плане, что хороший программист - это уже руководитель, поскольку постоянно принимает решения в условиях неопределенности, а также способен к абстракции - увидеть сущность объекта/процесса (в статье упоминается ООП в широком смысле) под наслоением малозначимой атрибутики. Нужно только научиться организовать работу команды ("надо работать").
(6) Я сам с командой делал проект большой и успешный. Но там руководитель проекта только орал при задержке этапов и выбивал/предоставлял ресурсы. Т.е. как в 1) моего 4-го поста.

12. bb1962 993 15.03.11 10:52 Сейчас в теме

(8)(9) Тогда нужно изменять систему голосования, иначе не понять кто за, кто против.
Статья моего оппонента не дискуссионная, это не призыв к обсуждению, это
УТВЕРЖДЕНИЕ.

14. Alraune 1507 15.03.11 11:03 Сейчас в теме

(12)

Поставьте плюс, если вы рекомендуете данную публикацию к прочтению и использованию

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

15. Арчибальд 2712 15.03.11 11:03 Сейчас в теме

(12)

Статья моего оппонента не дискуссионная, это не призыв к обсуждению, это
УТВЕРЖДЕНИЕ.

Но обсуждение из 138 постов все же случилось ;)
(13) Компьютер должен работать, а человек - думать.

9. Alraune 1507 15.03.11 10:36 Сейчас в теме

(7) Мой плюс тоже и там, и там. Публикация как повод к размышлению и обсуждению часто заслуживает плюса вне зависимости от того, разделяю я мнение автора или нет.

17. tango 553 15.03.11 11:13 Сейчас в теме

(7) пошел поставил -

19. Арчибальд 2712 15.03.11 11:31 Сейчас в теме

(17) Это ты погорячился...

36. Spartan 366 15.03.11 15:35 Сейчас в теме

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

16. tango 553 15.03.11 11:11 Сейчас в теме

(6) есть, есть, мое предпоследнее место работы - БТК: крутецкий оптовик всего, что втыкается в розетку, не менее двух лет БиТ сосал бабло, УТ+Инталев, в результате одного ключевого пользователя (продажника) уволили, другой (финдир) в конце проекта писал "все проводки неправильные", прогнали битовцев, уволили всех. кого брали на подхват. начали сокращать своих штатных 1снегов, завели речи о возврате на 7.7
руководитель от БиТа "Кирилл Гусев":mailto:kgusev@1cbit.ru

18. tango 553 15.03.11 11:24 Сейчас в теме

+(16) форма расходного ордера на определенную выплату содержала пять (пять!) разных реквизитов, которые должен был заполнить оператор, чтобы указать системе, что это ордер именно на такого рода определенную выплату

10. yangusarov 15.03.11 10:47 Сейчас в теме

Зэ бэст оф зэ бэст - это когда руководитель проекта + хороший программист-внедренец = хэппи енд проект.

11. RustIG 1990 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. Арчибальд 2712 15.03.11 11:57 Сейчас в теме

(20) Надо. Над собой :D

22. bb1962 993 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" (кто знает - поймет :) ).
В США полагают, что без прочтения книги Брукса не может состояться ни один руководитель программного проекта.
---
А если взять нашу, российскую реальность, то, ес-сно, когда босс ни черта не понимает в разработке,
ориентирован только на зарабатывание "буказоидов", и при слове "ТЗ" впадает в ступор, то можно легко представить
итоговое качество и сроки проекта... :)
Еще раз - ОГРОМНОЕ СПАСИБО автору !!!

24. RustIG 1990 15.03.11 12:30 Сейчас в теме

+ (23) http://www.ozon.ru/context/detail/id/83760/

26. bb1962 993 15.03.11 12:56 Сейчас в теме

(24)(25) Может быть все-таки почаще в отладчике тексты читать?

28. cool.vlad4 2 15.03.11 13:14 Сейчас в теме

(26)?

Прикрепленные файлы:

27. Арчибальд 2712 15.03.11 13:06 Сейчас в теме

(23) (24) (25) На Инфостарте есть все
http://infostart.ru/public/72612/ ;)

29. vkr 15.03.11 13:52 Сейчас в теме

(27) Лучше уж тогда - с картинками :), вот отсюда :
"Мифический человеко-месяц..." (в формате PDF, 1.5Мб)

30. Арчибальд 2712 15.03.11 14:07 Сейчас в теме

(29) У меня именно с картинками. Из юбилейного издания 95 года

31. cool.vlad4 2 15.03.11 14:21 Сейчас в теме

(29) на либрусеке вообще-то с картинками ...добавлять некогда было в архив...

32. Alraune 1507 15.03.11 14:36 Сейчас в теме

(31) С картинками, да. Сейчас сижу, читаю. Спасибо за ссылку)))

25. cool.vlad4 2 15.03.11 12:49 Сейчас в теме

http://lib.rus.ec/b/146089/

Прикрепленные файлы:

mithsoftware.rar

33. tango 553 15.03.11 14:56 Сейчас в теме

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

37. Spartan 366 15.03.11 15:37 Сейчас в теме

del

42. awk 745 15.03.11 16:41 Сейчас в теме

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

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

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

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

43. Трактор 1299 15.03.11 16:57 Сейчас в теме

(42)

Руководитель пишущий код - плохой руководитель.
...
1. Нехватка ресурсов.
2. Ненужность руководителя.

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

44. awk 745 15.03.11 18:12 Сейчас в теме

(43) Это не руководитель - это координатор. Не надо теплое с мягким путать. Координатором и секретарь может быть.

46. Трактор 1299 15.03.11 18:19 Сейчас в теме

(44) Руководитель тот кто несёт ответственность за деятельность бригады, команды, группы, отдела. Если он при этом совмещает руководство с производственной деятельностью, то это руководитель по совместительству. А так получается что ты просто не признаёшь существование совместительства.

49. awk 745 15.03.11 18:43 Сейчас в теме

(46) Более того я не только его признаю, но и описываю ситуации возникновения данного явления. Один из которых - это простота проекта, при которой исполнитель может попеременно исполнять разные роли. Половина людей на этом сайте приходя к клиенту играют роль менеджера по продажам, сев за компьютер - руководителя, технического писателя, программиста, тестировщика (роль о которой все забыли), а вернувшись к клиенту с результатами - роль внедренца. Дальше больше - они начинают играть роль тех. поддержки.

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

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

51. Трактор 1299 15.03.11 20:51 Сейчас в теме

(49)

Отсюда и мое отношение к совместительству. Это либо жадность клиента, либо жадность исполнителя (руководителя).

И что ни разу на проекте не требовалось 1,5 программера и 0,5 рукля? Ой не верю! А если потребуется, то клиент будет платить за двух программистов и одного рукля. Накладненько выходит. При избытке клиентов, конечно, можно одного рукля нагрузить несколькими проектами, но так бывает не всегда.

Более того, рукль, который умеет кодить, но не кодит, со временем теряет квалификацию. Разучивается.

52. awk 745 16.03.11 00:05 Сейчас в теме

(51) Уж прости, но не бывает "полтора землекопа". Их либо два, либо один. Либо у проекта дефицит, либо профицит, либо проектов более одного.

53. Трактор 1299 16.03.11 00:16 Сейчас в теме

(52)

не бывает "полтора землекопа"

Ещё более не бывает людей, умеющих программировать, но не программирующих. Твоё пожелание о том что рукль проекта должен уметь

встать(а не встает) на место подчиненного и выполнить за него работу

, но только в форс-мажоре. Или форс-мажоры должны быть постоянными или квалификация такого специалиста быстро упадёт.

54. awk 745 16.03.11 01:23 Сейчас в теме

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

55. bb1962 993 16.03.11 06:03 Сейчас в теме

(54)

awk пишет:
Правда, пишу все реже и чаще для себя

Это всего лишь возраст, чем бы Вы себя не утешали.
Не всем дано быть программистами до 60-ти.
Это не хорошо и не плохо, это - жизнь.

56. 16.03.11 06:17 Сейчас в теме

(54) У меня похожее правило, только оно называется так: приступать к выполнению конкретных задач, только если загружены все участники, в соответствии с приоритетами. Пока кто то начал уходить от приоритетов или халтурить - ищу причины, устраняю - это первостепенная обязанность если ты взял на себя ответственность за результат.

И если участники все заняты своими делами, тогда приступаю к выполнению сам, беру как правило те задачи, которые не потянуть не программистам, не консультантам. Это или конфликты или политика или улаживание противоречий между различными сторонами. Ну а когда время освобождается на старое и доброе программирование так что получается уйти в него с головой и не думать о течении проектов, ну это почти что праздник души ))

47. 15.03.11 18:32 Сейчас в теме

Ответственность штука сложная. На много сложнее взять на себя ответственность и выполнить обязательства любой ценой.
Гораздо проще мнить себя пупом земли, выполнять свои должностные инструкции, и дальше мониторов не заглядывать.
А управление это способность достигать результатов. Что для этого нужно? Да все!
Надо - глав.буха соблазнишь, надо - столы потаскаешь, в гостиницах без отопления поспишь, в самолетах полетаешь без передышки неделю, выслушаешь какой ты козел от 8 из 10 сотрудников, пару ночей без сна перебьешься перед закрытием проекта...
И все эти особенности как правило знают лишь те кому приходилось нюхать такое слово как ответственность, чтобы зарплату получали те кто кроме программирования в этой жизни ничего не хочет.

48. cool.vlad4 2 15.03.11 18:36 Сейчас в теме

"Наилучший руководитель - тот, о котором люди знают только, что он существует. Когда его работа выполнена, они скажут: ‘Мы сделали это сами’". ( Лао Цзы)

50. tango 553 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 553 16.03.11 09:22 Сейчас в теме

общепризнанные = признанные мной - позиция ожидаемая.

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

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

**
минус в (57) - за голимую саморекламу

61. Арчибальд 2712 16.03.11 09:32 Сейчас в теме

(60) А нужен ли архитектор при строительстве хрущоб? Там прораба достаточно.

62. vkr 16.03.11 09:41 Сейчас в теме

(61) Присоединяюсь!
А нужно ли вообще строить хрущобы ?
Может, немного подумать головой и построить что-то получше - где и архитектор нужен ? :)

64. tango 553 16.03.11 09:46 Сейчас в теме

(61),(62)

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

пример "эффективного менеджера" : чубайс - авария в СШ, цены на энергию

69. awk 745 16.03.11 11:08 Сейчас в теме

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

70. tango 553 16.03.11 11:29 Сейчас в теме

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

73. awk 745 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 745 16.03.11 12:28 Сейчас в теме

(74) Заблуждаетесь. Заказчик никогда не знает что ему нужно, в какие сроки это будет сделано, какова себестоимость. Он может ответить только на вопрос сколько он готов заплатить и кому.

80. tango 553 16.03.11 12:30 Сейчас в теме

+(78) ... кому конкретно. тендер, понимаешь

81. awk 745 16.03.11 12:40 Сейчас в теме

(80) Забыл в (73) роль "Менеджер по продажам (Как объяснить клиенту, что это надо делать за N$ период Т и в конторе "Рога и копыта" :))" - позор на мои седые волосы...

82. vkr 16.03.11 12:47 Сейчас в теме

(78) Я, конечно понимаю смысл Вашего возражения - в контексте книжек типа "Физики шутят"... :)
Но ведь, по большому счету, нормальный заказчик знает - ЧТО он хочет получить (eg, систему учета "Рога и копыта"),
срок и примерную сумму, за которые он хочет это получить. А уж на сколько его попытаются развести - бог знает...
Наверное, если руководитель проекта - из программеров, то заказчику будет легче... В России, по крайней мере... :)

83. awk 745 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", либо пользователь этого не понимает, но тогда уже ничем помочь нельзя

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

65. tango 553 16.03.11 09:50 Сейчас в теме

(63) и другие:
Что значит "взять на себя ответственность"

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

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

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

конкретно, в чем заключалась ваша ответственность как РП, во-первых, перед подчиненными, во-вторых, перед заказчиком.
конкретно - ваша, и конкретно - сколько
ну, т.е, ваши подчиненные знали, что если проект провалится, вы ответите конкретной суммой денег?

67. warden 101 16.03.11 10:09 Сейчас в теме

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

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

68. tango 553 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 553 16.03.11 12:24 Сейчас в теме

(72) еще одна характерная примета: "вот обьяснить Вам, что значит "управлять""

я не просил объяснять это, я просил (риторически) сказать, в чем заключается ваша "ответственность", из-за которой ушей не видно.

84. warden 101 16.03.11 13:27 Сейчас в теме

(76)

я не просил объяснять это, я просил (риторически) сказать, в чем заключается ваша "ответственность", из-за которой ушей не видно

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

89. tango 553 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. Арчибальд 2712 16.03.11 11:38 Сейчас в теме

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

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

75. Арчибальд 2712 16.03.11 12:22 Сейчас в теме

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

© Alan Carter The Programmers' Stone (Программистский камень)

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

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

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

Ответить

77. tango 553 16.03.11 12:28 Сейчас в теме

(75) я с шестерки двигатель снимал в одиночку. разобрал, собрал и поехал :)

85. Spartan 366 16.03.11 13:54 Сейчас в теме

(75) В точку. Именно об этом я и пытался сказать в (36). Авторы спорят о разных вещах...

79. Арчибальд 2712 16.03.11 12:29 Сейчас в теме

И еще одна цитата http://ailev.livejournal.com/470473.html

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

86. venger 2127 16.03.11 14:09 Сейчас в теме

Если так случилось, что руководитель проекта не программист, то все просто - он должен организовать "кофе, чай и бутерброды" программистам, а дальше все зависит от них (как всегда), смогли самоорганизоваться, выбрать из своего круга "теневого" руководителя и выполнить работу - молодцы, нет - значит, можно сказать, что руководитель не программист, не профессионал, в этом все дело, и дальше продолжать любить себя;-) Программисты всегда в выигрыше, в общем;-)

88. dabu-dabu 390 16.03.11 15:03 Сейчас в теме

Обе статьи по большому счету - верные, просто для разных ситуаций.

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

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

На мелком проекте - должности руководителя, ведущего специалиста, программиста, консультанта обычно объединяются в одном человеке и это абсолютно оправдано. При этом он должен быть прежде всего программистом-консультантом, т.к. управлять ему все равно по большому счету некем.
На среднем проекте - обычно должности руководителя, ведущего специалиста - один человек.
На крупном проекте - руководить должен заниматься только руководством и не чем больше.
Нельзя одновременно быть и отличным программистом (консультантом) и отличным руководителем. А на крупных проектах руководитель должен быть только отличным. От руководителя в основном и зависит удачное завершение крупного проекта.

Ответить

90. tango 553 16.03.11 15:27 Сейчас в теме

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

92. dabu-dabu 390 16.03.11 16:15 Сейчас в теме

(90)

tango пишет:

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

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

96. tango 553 16.03.11 17:12 Сейчас в теме

(92)
- Премии
- Повышения (или более интересные-крупные-прибыльные проекты)
- Увольнение
- Плохие / хорошие характеристики (известность) и т.п.

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

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

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

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

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

105. dabu-dabu 390 16.03.11 23:21 Сейчас в теме

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

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

107. tango 553 17.03.11 07:54 Сейчас в теме

(105) программер из команды грохнуть может ту же самую базу, что и его РП
Востребованность - это опять таки мотивация из разряда зарплатных. Я же оспроривал "ответственность", преподносимую как нечто функционально, "ролево" (?) отличающее РП от члена команды. И показывал, что это - всего лишь самомнение.
То, что "особо крупные" РП - штучный товар, это во всех отраслях так. Я уже упоминал чубаса - провалил, гад, все, где пометился, и ничего. Связи,понимаешь. Ответственность - в терминах оппонента...
(106) а плюсь? :D

111. dabu-dabu 390 17.03.11 10:05 Сейчас в теме

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

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

113. tango 553 17.03.11 10:14 Сейчас в теме

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

120. Арчибальд 2712 17.03.11 10:47 Сейчас в теме

(111)

указать свое мнение, что это может привести к провалу проекта. Тем самым РП может снять с себя часть ответственности

И что от ответственности останется?

Когда РП берется за проект, он должен сам нанять программистов

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

126. awk 745 17.03.11 11:08 Сейчас в теме

(120) Я бы добавил, что человек не имеющий опыта провалов - это неопытный человек.

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

"Теория без практики - слепа, а практика без теории опасна." (с) М. Ломоносов.

144. dabu-dabu 390 17.03.11 12:51 Сейчас в теме

(120)

И что от ответственности останется?

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

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

146. Арчибальд 2712 17.03.11 13:30 Сейчас в теме

(144)

Так может высказаться только тот, кто не только в программировании не разбирается, но и программистов видел только на картинке.

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

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

151. dabu-dabu 390 17.03.11 14:13 Сейчас в теме

(146) Из этого следует, что программист - главный, а РП в идеале совсем не нужен?
Вопрос, что должно входить в обязанности программиста?

108. Арчибальд 2712 17.03.11 09:10 Сейчас в теме

(105) Это уж ни в какие ворота. Если в проваленном проекте есть программист, вся ответственность будет на нем, однозначно. РП могут лишь пожурить за "ошибку" в выборе программиста. А программист, зная об этом, постарается проект вытянуть даже вопреки действиям РП.
Конечно, к проекту, где нет программирования, это не относится.

109. tango 553 17.03.11 09:47 Сейчас в теме

(108) программист ... постарается

да ну? есть РП - ... ни бельмеса... кроме ответственности...
к пуговицам претензии есть?

ответственность РП - в терминах оппонента!! - помогает лишь выиграть тендер, когда у заказчика "ответственность" такая же (рыбак рыбака), но никак не выполнить проект. особенности национальных проектов на современном этапе, понимаешь

110. Арчибальд 2712 17.03.11 10:01 Сейчас в теме

(109) Да все и сведется к претензиям к пуговицам. Конечно, если аутсорсинг - ничего не произойдет. А если прогеру предстоит это дерьмо разгребать всю оставшуюся жизнь?

97. 16.03.11 17:15 Сейчас в теме

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

91. пользователь 16.03.11 15:28

Сообщение было скрыто модератором.

...

93. awk 745 16.03.11 16:17 Сейчас в теме

(88) А можно раскрыть "Средний проект". Как я понял это попытка определения перехода от мелкого к крупному. Где грань между мелким и средним? Или средним и крупным?

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

А недавно был реализаван мелкий проект, но там было более одного человека задействовано и руководитель отдельный был (1С + PHP + C#).

95. dabu-dabu 390 16.03.11 16:52 Сейчас в теме

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

PS Из слов "зелен и жаден я был" могу сделать предположение, что вы и "предприниматель", правда, который сам пытается сделать всю работу.
Так могу сказать, что это что угодно, но только не бизнес. Человеку, строящему свой бизнес не в коем случае нельзя спускаться до выполнения конкретной работы. Он должен решать только вопросы найма сотрудников с делегированием полномочий, развивать бизнес, выбирать направления деятельности, искать где бы взять денег или еще Клиентов и решать проблемы взаимодействия с государством. Предприниматель ни в коем случае не должен быть "жаден", он должен только решать проблемы эффективности. ИМХО

101. awk 745 16.03.11 18:02 Сейчас в теме

(95) "Зелен и жаден". В прошедшем времени - да, так и было. Загубил не одну фирму. И не только которая занималась разработкой ПО.
(99) Рейнвотер "Как пасти котов" - пытался найти не нашел. Остальные погуглю. Найду - почитаю.

98. 16.03.11 17:30 Сейчас в теме

tango пишет:
Тема была - почему валятся проекты. Вы прекрасно ответили: "выяснился ряд нюансов которые не учел"

см. сюда...

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

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

100. tango 553 16.03.11 17:50 Сейчас в теме

(98) да все с тобой было понятно еще по первой статье, вступи в единую росию и успокойся
100!

99. lustin 16.03.11 17:44 Сейчас в теме

awk пишет:

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

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

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

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

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

P.S. А знаете кстати, что считается правильным подходом в случаях если отличный управленец по проектам, не обладает достаточным техническим знанием - изыскивается человек/ресурс у которого навыки программиста будут преобладать над управленческими в том же соотношении, что и менеджера навыки управления преобладают над программисткими: и этот подход работает отлично, поверьте.
Отличительной особенностью такого подхода в крупных конторах, является наличие CIO и его заместителя по технической части, причем заместитель чаще всего не является по совместительству еще и начальником какого-нибудь отдела ИТ департамента.
И кстати, этот самый техничиский заместитель может,чаще всего хочет, и еще и участвует в написании кода, прототипов и ВНИМАНИЕ еще и документации.

102. lustin 16.03.11 18:30 Сейчас в теме

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

и еще книжка "в догонку" из тех которые "must read" как для разработчика, так и для руководителя проектами.
Эдвард Йордон - Путь камикадзе [Смертельный марш]

118. 17.03.11 10:44 Сейчас в теме

1. (102) ты забыл уточнить что это с точки зрения программиста ))
Если кто не в курсе то программисты тоже книги пишут, и само собой вкладывают в них свои точки зрения, в т.ч. свои стереотипы.
Скажем есть теория ЖЦ программирования (как видят этапы программисты), есть теория ЖЦ использования ПО (тут уже точка зрения от пользователей), при желании можно описать ЖЦ внедрения (с точки зрения внедренца). В мире все относительно. Не стоит про это забывать, а верить всему что написано в книгах как истине в последней инстанции - тем более )) Ну это опять же зависит от развитости воспрития мира и доступно не всем.
Взять ту же методологию управления программными проектами от MS, под названием SureStep... ну или ее аналоги... там этап разработки стоит как не обязательный, который можно пропускать, в отличие от иных этапов, в т.ч. установка, моделирование процессов и обучение.
Так что кидаться такими ссылками можно до бесконечности ))) И толку будет мало ))
2. (105) Поддерживаю. Опять же как сказал кто то из великих, понять действия человека можно лишь оказавшись на его месте. Те у кого уровень ответственности всегда ограничивался одним этапом, не понять тех кто отвечал за задачи целиком. И само собой если у тебя уровень когда тебя зовут главы предприятий и территорий, предлагают взяться за ту или иную задачу, то врятли тебя поймет человек который нанимается по объявлениям, резюме и сертификатам. Начиная с определенного уровня развития твои бумажки уже никого не волнуют, волнует то что говорят о тебе люди на верху.
3. (107) Чубайса не трогай )) будешь иметь право его хаять когда хоть тысячную долю его уровня ответственности хлебнешь. Я общался с людьми которые реформировали энергетику под его руководством. Уровень задачи и стратегия ее решения была на высоте. Мало кто в России сумел бы повторить что то в его духе. И не связи его красят. Просто есть планка, ниже которой люди грызутся и хаят все что не по их мнению (быдло, ведомые, ученики), а выше этой планки у людей совершенно другой тип восприятия (элита, ведущие, мастера - в разных религиях их называют по разному). И там даже к крупным ошибкам относятся с пониманием, т.к. сами все в шрамах от ударов судьбы. Кто через это не прошел, тому это не понять.
4. (112) Не льсти себе, ты не тот человек на кого стоит тратить время чтобы что то объяснять и разъяснять. Пользы от этого нет. Никому. Да и не объяснить тебе всего этого, даже с картинками и на пальцах. Тут только опыт. Пройдешь через это - поймешь. Нет - ну значит не твое это.

121. tango 553 17.03.11 10:50 Сейчас в теме

минус за (118) объяснен в последней фразе (112)

131. lustin 17.03.11 11:34 Сейчас в теме

A.Y пишет:

1. (102) ты забыл уточнить что это с точки зрения программиста ))

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

Скажем есть теория ЖЦ программирования (как видят этапы программисты), есть теория ЖЦ использования ПО (тут уже точка зрения от пользователей), при желании можно описать ЖЦ внедрения (с точки зрения внедренца). В мире все относительно. Не стоит про это забывать, а верить всему что написано в книгах как истине в последней инстанции - тем более )) Ну это опять же зависит от развитости воспрития мира и доступно не всем.

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

Так что кидаться такими ссылками можно до бесконечности ))) И толку будет мало ))

Я не забывал уточнять, я просто это не указал, потому что это нет так.

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

Процитирую опять Брукса (который кстати вообще то считается ученым)
"не существует универсального метода предотвращения перерасходов и провалов проектов. В целом, проекты в ИТ — достаточно большие, сложные, плохо документированные и затрагивающие непривычные аспекты — по-прежнему могут подвергаться крупным непредвиденным проблемам"
Я вообще довольно холодно отношусь к методикам типа "Серебрянной пули"
Именно поэтому я вам за Вашу статью про "4 серебрянных пули" поставил минус.

Вы более интересные мысли высказываете в своих комментариях - если вы их соберете в одну статью: вот такая статья действительно будет содержательной.

P.S. И еще я не "кидаюсь ссылками" - я обращаю внимание собравшихся, что необходимо знать теоретические основы, изложенные в различных книгах
учеными которые потратили жизнь на исследование проблем, с которыми вы столкнулись.

103. tango 553 16.03.11 19:50 Сейчас в теме

awk пишет:
Как пасти котов" - пытался найти не нашел

http://webreading.ru/conv/do_rtf.php?name=/books/comp_/comp_programming/reynvoter_dzh_hank_kak_pasti_kotov_nastavlenie_dlya_programmistov,_rukovodyaschih_drugimi_programmistami

106. awk 745 16.03.11 23:49 Сейчас в теме

(103) Огромное спасибо.

104. tango 553 16.03.11 19:53 Сейчас в теме

desty пишет:
Эдвард Йордон - Путь камикадзе [Смертельный марш]

"безнадёжные проекты становятся «стилем жизни» многих организаций"

:)

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

112. tango 553 17.03.11 10:10 Сейчас в теме

в прошлом году, когда БиТ провалил проект БТК, куда меня брали на подхват, рынок труда слегка просел.
и я подписался на шняжную контору, рекомую Евроконсалт
http://www.evroconsult.ru/

главный 1снег там вкусил участия в тендерах, и, благодаря весьма развитой "ответственности", стал их выигрывать.
На деле - за счет "сбалансированного" бюджета.
Сбалансированного, разумеется, за счет членов команды, в т.ч. меня.
Дергаться не хотелось, да и интересно было (завод 10 000 чел.).

Результат: я свои этапы (2 из 4) сдал в сроки - от ТЗ до актов приемки.
А два этапа (Буз и ЗиК) - просели.
В результате - мне премию не дали тоже. Полгода, получается, я сидел на голом (маленьком) окладе.
Ну, я огорчился и ушел.
Очень сомневаюсь, что они найдут (в рамках первоначального бюджета) 1снега, который сможет продолжить мой участок.
Очень хотелось написать туда (на завод) письмо, мол, ребята, если этот РП не сможет, я тут... Но, блин, не настолько я "ответственный", чтобы решать чужие проблемы.
Вот такая бадья, прикинь?

Это к чему?
Я просил оппонентов раскрыть содержание их "ответственности" перед сотрудниками - они не смогли (не стали, не захотели). Ну и нех тут п..деть.

114. dabu-dabu 390 17.03.11 10:24 Сейчас в теме

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

116. tango 553 17.03.11 10:38 Сейчас в теме

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

А вообще я хотел просто повторить это:
http://forum.infostart.ru/forum24/topic33943/message385361/#message385361

115. pula123430 17.03.11 10:36 Сейчас в теме

автор просто не понял статью которую критиковал. и еще он не держит понятие "управленец", для него управление - это просто доп.функция, а не отдельная профессия.

117. tango 553 17.03.11 10:42 Сейчас в теме

(115) не так. опровергалось утверждение, что управленец в проектах внедрения 1С может не шарить в конфигураторе, если речь не идет о "внедрении" типовых конфиг (этим занимаются менеджеры продаж + сервис-инженеры + консалтеры-обучатели, называть их координатора-диспетчера руководителем проекта - чересчур претензиозно).
Он может не шарить, если есть отдельный чел - архитектор системы. Но такой архитектор должен обладать правом решающего голоса, и тогда РП - просто прораб.

119. btr 17.03.11 10:45 Сейчас в теме

Не нужно путать должностные обязанности ведущего программиста (ГИПа, главного инженера проекта) и руководителя проекта.
Есть масса программистов, которые еще не доросли даже до ведущего.
Руководство проектом - это в чистом виде административная должность.
Открываем практики управления проектами и изучаем.

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

Почему вечно люди делают безапелляционные заявления по вопросам, в которых не имеют ни опыта, ни знаний, а только разрозненные начальные навыки, случайно приобретенные, и даже не отрефлексированные толком?

122. tango 553 17.03.11 10:56 Сейчас в теме

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

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

123. btr 17.03.11 11:02 Сейчас в теме

Если уж на то пошло, обе статьи глубоко ошибочны.

Необходимо четко разделять процессы и процедуры проекта на несколько контуров

1. Организация проекта (целеполагание, структурирование ответственности и обязательств, обоснование и обеспечение ресурсами)
2. Администрирование проекта (организация коммуникации, формализация задач, вех, артефактов, согласование точек зрения, выявление разногласий, проблем, эскалация конфликтов, дипломатическое урегулирование, контроль за исполнением сроков, задач, бюджета, мониторинг рисков и эффективности, управление изменениями, подготовка и презентация результатов проекта по планируемым и выполненным работам, взаимодействие с заинтересованными лицами, управление мотивацией заказчика и исполнителей)
3. Инженерное обеспечение проекта (определение и структурирование задач, выполнение и сдача приемка работ, оценка необходимости и достаточности ресурсов)
4. Финансирование проекта (оценка и привлечение средств, отчетность по освоению и получаемому эффекту, интегральная и частная оценка финансовых показателей проекта)
5. Надпроектное управление (оценка с точки зрения программы или портфеля проектов, интеграция процедур и процессов проекта в бизнес-деятельность, управление развитием процессов и процедур, повышение зрелости проектных процедур и процессов, управление квалификацией персонала и качеством используемых ресурсов)

Пока Вы не способны рассматривать все процессы и процедуры проекта - Ваша зрелость как руководителей проектов весьма не высока (не выше уровня 2 по организационной модели зрелости)

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

Не важно, сколько человек участвует в проекте. Важно, насколько ясно они себе представляют процессы и процедуры управления проектами, а так же цели, риски и ограничения данного конкретного проекта.

124. Трактор 1299 17.03.11 11:05 Сейчас в теме

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

Опыт Королёва, Курчатова и Ландау тебя опровергает.

145. Ish_2 1117 17.03.11 13:16 Сейчас в теме

(124) Королев не был "ни ученым , ни инженером".
В давней телевизионной передаче было сказано Раушенбахом именно так .
Вот что он пишет (правда, уже немного по-другому) :
"Я в свое время долго размышлял о Королеве, фон Брауне, которые действительно совершили крупные открытия, я бы сказал, открытия общемирового значения, и думал, как их назвать одним словом: великий ученый, великий инженер? Все это ерунда. Великих ученых много, много и великих инженеров, а эти люди были явлениями уникальными. И я не придумал лучшего слова, чем полководец."
http://azbyka.ru/moi_put_k_vere/raushenbah-all.shtml

В контексте текущего разговора , думаю , возможно определить : "полководец = РП".

147. Арчибальд 2712 17.03.11 13:47 Сейчас в теме

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

149. Ish_2 1117 17.03.11 14:00 Сейчас в теме

(147) Я в аналогиях не силен.
Я понимаю тебя прежде всего как практика , который наелся г.. в небольших проектах.
Но это не значит , что ты прав.
Разберем обмен репликами :

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

- Так может высказаться только тот, кто не только в программировании не разбирается

Твоя фраза опровергается очень просто.
РП имеет больше опыта в программировании, чем подчиненный программист.
И тогда всё становится на свои места.

НО твои оппоненты толкуют о другом, о более крупных проектах, где, представь себе ,
РП может и не быть программистом вовсе. И даже лучше когда он не программист, а менеджер.

150. Трактор 1299 17.03.11 14:07 Сейчас в теме

(149)

НО твои оппоненты толкуют о другом, о более крупных проектах, где, представь себе ,
РП может и не быть программистом вовсе. И даже лучше когда он не программист, а менеджер.

Я привёл примеры очень крупных проектов где руководители были специалистами. Приведи обратные примеры, например где руководитель совсем не рубит в предметной области. Чубайс подойдёт.
А вот Билл Гейтс и Стив Джобс они таки хорошо знают предметную область.

152. Ish_2 1117 17.03.11 14:13 Сейчас в теме

(150) Что ж , сугубо личное мнение , основанное на всем доступной информации :
Чубайс - РАО ЕЭС, Сердюков - МО.

153. Трактор 1299 17.03.11 14:18 Сейчас в теме

(152) Результаты деятельности Чубайса в РАО АЭС сильно неоднозначны.
Сердюков пока свою деятельность не закончил. Но его американские коллеги показали хорошие результаты. В своё время в США был серьёзный срач между родами войск и военный министр обороны втягивался в этот срач. Назначение гражданского министра обороны решило вопрос срача и повысило обороноспособность. Пример принимается. Хороший пример.

154. Ish_2 1117 17.03.11 14:25 Сейчас в теме

(153) Минуточку. Чубайсом заранее была объявлена цель проекта : ликвидация РАО ЕЭС.
Цель была достигнута. Он - эффективный менеджер, сказал - сделал.
Как к такой реформе относиться - это другой вопрос, вне рамок обозначенного проекта.

156. Трактор 1299 17.03.11 14:34 Сейчас в теме

(154)

Ish_2 пишет:
Чубайсом заранее была объявлена цель проекта : ликвидация РАО ЕЭС.

Мне помнится что цель была другой "Повышение эффективности деятельности энергетического сектора путём создания конкуренции на энергетическом рынке." А уж ликвидация РАО ЕЭС лишь средство достижения цели. Повысилась эффективность или нет предлагаю тут не обсуждать.

157. tango 553 17.03.11 14:37 Сейчас в теме

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

155. Арчибальд 2712 17.03.11 14:26 Сейчас в теме

(149)

РП имеет больше опыта в программировании, чем подчиненный программист.
И тогда всё становится на свои места.

Буквально: РП - опытный программист. И тогда все становится на свои места.
(151)

Из этого следует, что программист - главный, а РП в идеале совсем не нужен?

... Из вас двоих главнее тот,
Кто без другого проживет.
Ты проживешь без королей?
Солдат сказал: Изволь!
А ты без гвардии своей?
Ну нет! - сказал король.
© Р. Бернс

Король - это не профессия. Еще работать надо.

158. Ish_2 1117 17.03.11 14:38 Сейчас в теме

(155) Ты не понял Бернса. Его стишок - о глупости солдата.
Связь "Король-солдат" аналогична связи "голова-нога" .
И если глупая "нога" считает, что может обойтись без "головы".
То умная "голова" понимет , что без "ноги" ей никак.

163. Арчибальд 2712 17.03.11 14:59 Сейчас в теме

(158) Принято. Тогда вот тебе частушка от имени РП:

Хорошо тому живется,
У кого одна нога:
И штанина не порвется
И не надо сапога.

(159) Несомненно.

165. tango 553 17.03.11 15:04 Сейчас в теме

+(163) и танцевать удобно

160. dabu-dabu 390 17.03.11 14:45 Сейчас в теме

(155) Однако стран без "королей" никогда не было. Даже анархия подразумевает какое-то лидерство.
РП также без подчиненных это нонсенс. Когда говорится руководитель подразумевается, что он кем-то руководит.
Я также не говорю, что РП важнее программиста (я боюсь, что скатывание спора происходит в эту сторону).
Я писал ранее:

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

125. btr 17.03.11 11:06 Сейчас в теме

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

Что за глупая идея? С какой стати "чубас" - руководитель проекта :) Он даже не потребитель, а только спонсор. Не надо тиражировать глупости неосведомленных людей, даже не обдумав их.

Руководитель проекта НЕ СТАВИТ задачи. Он согласовывает поставленные ГИПами задачи с целями, задачами и ограничениями проекта.

134. tango 553 17.03.11 12:09 Сейчас в теме

(125) "Он даже не потребитель, а только спонсор"
так чубас - спонсор? а мужики-то и не знали... и много он вложил кровных, непосильным трудом нажитых?

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

Прикрепленные файлы:

136. awk 745 17.03.11 12:18 Сейчас в теме

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

139. tango 553 17.03.11 12:32 Сейчас в теме

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

143. btr 17.03.11 12:50 Сейчас в теме

tango пишет:

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

(135) "Как раз коррелляция заметна между неуважением "спецов" к "администраторам"."

корреляция бывает между чем-то и чем-то

О, да, прошу прощения :) Корреляция между неуважением спецов к администраторам и отстаиванием здесь точки зрения, что руководитель проекта обязательно должен быть самым лучшим программистом в проекте :)

Ну, а то, что Гитлер, увы, был очень значимым лидером и очень сильным политиком - бесспорно. Молоток, как инструмент - вне морали. Так же как и организаторский талант.

135. btr 17.03.11 12:16 Сейчас в теме

tango пишет:

(125) "Он даже не потребитель, а только спонсор"

так чубас - спонсор? а мужики-то и не знали... и много он вложил кровных, непосильным трудом нажитых?

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

Как раз коррелляция заметна между неуважением "спецов" к "администраторам". Когда это они уважали чужой труд? :) Только спецы - непревзойденные гении. А когда они заваливают проект по причине его неорганизованности, неструктурированности, несогласованности, противоречивости, неправильного определения приорититов, эффективности и отдачи вложенных средств - конечно же виноваты не они :)

Чубайс - распорядитель средств, в том числе и бюджетных. Мужики много чего не знают, просто потому что и не пытались узнать. Достаточно людей, доверяющих Чубайсу свои средства. Они как-то забыли поинтересоваться мнениями мужиков. А моська - знать она сильна, что лает на слона ;) Show me money, Buddy. Мнение каждый может иметь. Вопрос, что оно (мнение) тебе дает? Не вижу смысла обсуждать здесь Чубайса.

Вопрос конкретный - как организованы твои проекты? Сильно тебе помогает в организации знание программирования или предметной области? На форуме болтать - все умные и опытные.

137. tango 553 17.03.11 12:28 Сейчас в теме

(135) ну, да, конкретно: Королев - исключение, чубас - спонсор... о разнице между распилом бюджета и безвозмездном (имиджевом) отдавании своих мужикам не ведомо
кстати. я здесь уже рассказал о своем участии в двух последних проектах. твоя очередь ...

127. Арчибальд 2712 17.03.11 11:09 Сейчас в теме

А вообще-то, все, что касается проектов с программированием, есть у Брукса.

Возможны три типа отношений, и все они с успехом встречаются на практике.
Одно и то же лицо может быть продюсером и техническим директором. Это вполне оправдано в маленьких командах, насчитывающих от трех до шести программистов. В более крупных проектах это очень редко осуществимо по двум причинам. Во первых, редко встречаются люди, сочетающие в себе большие административные и технические способности. Мыслители встречаются редко, практики ещё реже, но реже всего — мыслители практики.
Во вторых, в больших проектах выполнение каждой из функций требует полного рабочего дня или даже больше. Продюсеру трудно передать кому либо достаточную часть своих обязанностей, чтобы высвободить время для технической работы. Директору невозможно передать свои обязанности, не нанося ущерба концептуальной целостности проекта.
Продюсер может быть начальником, а директор — его правой рукой. Сложность здесь состоит в том, чтобы определить полномочия директора при принятии технических решений, с тем чтобы он не тратил своё время, участвуя в административной цепочке.
Очевидно, продюсер должен объявить о полномочиях директора в технической области и в высшей степени укреплять их в возникающих спорных ситуациях. Чтобы это было возможно, продюсер и директор должны иметь схожие взгляды по основным техническим вопросам. Они должны частным образом согласовывать основные технические проблемы, прежде чем они встанут на повестку дня. Продюсер должен также с большим уважением относиться к техническому мастерству директора.
Что менее очевидно, продюсер может с помощью символов статуса (таких как размер кабинета, ковровое покрытие, мебель, рассылка вторых экземпляров документов и т.п.) подчёркивать, что директор, находясь вне административной цепочки, обладает, тем не менее, властью в принятии решений.
Это может действовать очень успешно. К несчастью, к этому редко прибегают. Что хуже всего получается у менеджеров проектов, — так это использование технического гения людей, не очень сильных в администрировании.
Директор может быть начальником, а продюсер — его правой рукой. Роберт Хайнлайн ярко описывает такую организацию в «Человеке, продавшем Луну».
....
Такая организация тоже может эффективно действовать.
Мне кажется, что последний тип организации лучше подходит для небольших команд, описанных в главе 3 «Операционная бригада».<приложенная картинка> Полагаю, что продюсер в качестве начальника более подходит для больших поддеревьев действительно крупных проектов.

Здесь продюсер - это РП, а директор - ведущий программист.

Прикрепленные файлы:

128. Yashazz 4931 17.03.11 11:13 Сейчас в теме

В начале статьи A.Y чётко постулировано, что РП может быть дядей со стороны, менеджером-управленцем-организатором. Так вот за одно это уже можно лепить минус, что я и сделал. Любить родину, т.е. уметь созывать совещания и составлять красивые неработающие таблички, а равно топать ногами и орать, мало. Надо ещё понимать предметную область и уметь мыслить сущностями, которыми оперируют автоматизаторы.

129. awk 745 17.03.11 11:25 Сейчас в теме

(128)

В начале статьи A.Y чётко постулировано, что РП может быть дядей со стороны, менеджером-управленцем-организатором. Так вот за одно это уже можно лепить минус, что я и сделал.

Обоснуй. А то это:

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

не обоснование - это общие субъективные ощущения в духе: "Он меня не понимает".

130. Арчибальд 2712 17.03.11 11:32 Сейчас в теме

(128) Там постулировано, что РП не может, а должен быть организатором. И это абсолютно правильно даже для программных проектов, не говоря уже о внедренческих. Анатолий слонен к второму (по Бруксу) варианту, и для внедренческих проектов это наиболее продуктивно (с учетом моего выделения в цитате из Брукса).
А в данной статье речь идет о программных проектах, и отстаивается третий (по Бруксу) вариант. И я уверен, что во "внутренних" программных проектах, где задействовано не более 5-7 человек, этот третий вариант оптимален. Но с одним условием: у администратора (с картинки) должен наличествовать реальный административный ресурс.

233. Yashazz 4931 18.03.11 13:54 Сейчас в теме

(130) Видишь ли, можно написать много умных и правильных вещей, основанных как на теории, так и на опыте. И в процессе содержательной дискуссии в этой теме и той были высказаны замечательные вещи. Просто есть один аспект, который как-то упустили, а он весьма значимый.

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

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

235. awk 745 18.03.11 15:14 Сейчас в теме

(233) Тогда по твоей логике надо минусовать и эту статью. Причем с большей активностью, чем ту. Просто в ней банально ошибок больше. Ни та - ни другая статья не тянет на плюс, хотя первая и имеет более близкое расположение к реальному миру. Это я как руководитель не в IT - ставший программистом, и как руководитель IT, бывший программист сужу. Исходя из прочитанной мной литературы по управлению, книг по программированию и опыта (руководства людьми и написания программ).

132. Spartan 366 17.03.11 11:41 Сейчас в теме

(128) Где там есть хоть слово про то, что РП не обязан "понимать предметную область и уметь мыслить сущностями, которыми оперируют автоматизаторы"?

133. btr 17.03.11 11:44 Сейчас в теме

Трактор пишет:
Опыт Королёва, Курчатова и Ландау тебя опровергает.

Это исключения, лишь подтверждающие правило. И Королев, и Курчатов, и Ландау подчинялись министрам, согласовывали с ними и планы и графики работ, и результаты, которые требуются от их проектов.

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

И если все проекты поставить в зависимость от таких гениальных менеджеров-инженеров, то количество масштабных проектов в мире потребуется сократить до 10-15 в год. По числу таких людей, одинаково талантливых и в инженерном деле, и в руководстве людьми.

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

141. vkr 17.03.11 12:41 Сейчас в теме

(133) Ну да, если учесть, сколько стен они были вынуждены прошибать во имя цели (скажем так - на благо общества)...
А сегодняшние "проекты" во главе с упоминавшимися тут РП - во имя "срубания бабла" :)
Ну, и действия их - соответствующие, и результаты - тоже... :)
(138) Да не вопрос... :)

142. btr 17.03.11 12:47 Сейчас в теме

vkr пишет:

(133) Ну да, если учесть, сколько стен они были вынуждены прошибать во имя цели (скажем так - на благо общества)...

А сегодняшние "проекты" во главе с упоминавшимися тут РП - во имя "срубания бабла"

Ну, и действия их - соответствующие, и результаты - тоже...

Мы все-таки говорим о несколько другом уровне проектов. Не во имя блага общества - точно.

Думаю, мнения уже высказаны, дальше копья ломать смысла не вижу. Если кто-то из программистов считает себя хорошим руководителем проекта - я только рад. Мне приходится учить как программистов, так и руководителей проектов. Почему-то сами не растут на грядках, увы. Исключения есть, но их крайне мало для того, чтобы делать по 20-30 проектов в год.

148. Трактор 1299 17.03.11 13:54 Сейчас в теме

(133)

btr пишет:
Это исключения, лишь подтверждающие правило. И Королев, и Курчатов, и Ландау подчинялись министрам, согласовывали с ними и планы и графики работ, и результаты, которые требуются от их проектов.

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

(136)

awk пишет:
Чубайс - спорная личность. Поверь, он отличный организатор.

Авария на СШГЭС и последствия ледяного дождя, может быть, результы того что он не владел предметной областью. Результаты Роснано тоже скромнее чем у Курчатова, Королёва или Ландау. Организатор-то он может быть и отличный, но ему, как специалисту по управлению, может быть результативнее возглавить институт управления.

К чему я это пишу. Да к тому что давайте отойдём от измышлений и посмотрим на практику. Предлагаю каждой стороне приводить примеры одни приводят примеры где специалист в предметной области был хорошим руклем, а вторые где рукль, слабо знакомый с предметной областью успешно завершал проекты. И, соответственно, примеры неудач тех и других.

138. 17.03.11 12:30 Сейчас в теме

btr,
Spartan,
Арчибальд,
awk,
Mahavishnu,
Alraune,
респект и уважуха за ваш опыт и умение мыслить абстрактно. успехов!

остальным удачи, может быть поможет )

140. tango 553 17.03.11 12:39 Сейчас в теме

(138) не надо и этого. просто не замечай моих постов, ладно?

159. awk 745 17.03.11 14:43 Сейчас в теме

И.В. Сталин - РП, Жуков Г.К. - ведущий программист, проект: Великая Отечественная. Проект завершен успешно.

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

Я читал мемуары Жукова (4 тома). Как РП Сталин - был вполне эффективен.

P/S
И не надо мне кричать что Сталин гад и убийца - я это знаю, но это отношение как к человеку и к методам достижения результата, а не как к руководителю.

Ответить

161. Трактор 1299 17.03.11 14:56 Сейчас в теме

(159) Прекрасно. Курчатова, Королёва и Ландау я уже приводил в пример. Гейтса, Джобса тоже. Добавлю авиаконструктора Илюшина и математика Колмогорова с его удачным проектом реформы образования в школе http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D0%BC%D0%BE%D0%B3%D0%BE%D1%80%D0%BE%D0%B2 Это примеры специалистов в предметной области, которые были и руководителями.

Итого 7 к 1.

166. Арчибальд 2712 17.03.11 15:04 Сейчас в теме

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

177. vkr 17.03.11 15:42 Сейчас в теме

(161)(166) Даже, скорее не Ильюшина, а Туполева с его легендарным единственным взглядом на чертеж - "Не взлетит"... :)
Какой из нынешних РП так скажет? Да побоиЦЦо попросту... :)
И чуть ближе к программированию - тот же Г.Н.Бабакин с его беспилотными МКК...

181. btr 17.03.11 15:56 Сейчас в теме

vkr пишет:

(161)(166) Даже, скорее не Ильюшина, а Туполева с его легендарным единственным взглядом на чертеж - "Не взлетит"...

Какой из нынешних РП так скажет? Да побоиЦЦо попросту...

И чуть ближе к программированию - тот же Г.Н.Бабакин с его беспилотными МКК...

Способность к быстрой интегральной оценке - не значит способности к разработке оцениваемого. Билл Гейтс не способен заменить собой большинство технических лидеров направлений MS не говоря уже о более узких специалистах-разработчиках. Когда-то, очень давно - мог. Стив Джобс вообще никогда не занимался собственно разработкой, только оценивал сами идеи с точки зрения их ценности для пользователей.

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

Но утрировать до "работать надо" - очевидная глупость. Никто не отправляет Билла Гейтса писать код Windows или Office. Курчатов не чертил лично чертежи и не слесарил с мужиками конструкции и узлы. Когда люди начинают фантазировать, чем занимаются их руководители, ни разу не попробовав их заменить - что они только себе ни нафантазируют.

Особенно полезны анархисты, конечно же :) За ними никого нет, и они не стоят больше почасовой ставки за выполняемый труд.
Умение создать команду, найти клиента и заработать - конечно же не нужное крутым перцам. За ними стоит очередь жаждущих их труда, зачем что-то организовывать? ;)

В общем, о чем спорить-то, жизнь все разложит по полочкам. Ждем новых Курчатовых, Гейтсов и Петров Первых.

183. vkr 17.03.11 16:03 Сейчас в теме

(181)

Но утрировать до "работать надо" - очевидная глупость. Никто не отправляет Билла Гейтса писать код Windows или Office. Курчатов не чертил лично чертежи и не слесарил с мужиками конструкции и узлы. Когда люди начинают фантазировать, чем занимаются их руководители, ни разу не попробовав их заменить - что они только себе ни нафантазируют.

Согласен с Вами - конечно же, никто никого никуда не отправляет... :)
Вот только спор, как мне кажется, все же о том, что должен ли РП пройти всю цепочку или ее бОльшую часть, прежде чем начать рулить...
Я думаю, что должен... Кстати, и Королев слесарил, и Курчатов чертил, и т.д. :)
А ждать новых РП класса указанных Вами - в текущей действительности и при таком отношении, мы, похоже, по гроб жизни будем.
З.Ы. Плюсик - осознанный.

184. tango 553 17.03.11 16:18 Сейчас в теме

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

185. btr 17.03.11 16:30 Сейчас в теме

vkr пишет:

(181)

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

Ответить

186. Трактор 1299 17.03.11 16:36 Сейчас в теме

(185)

Должен, должен РП побыть на месте своих сотрудников smile:) Но это не значит, что он должен стать выдающимся программистом, прежде чем станет успешным РП.
...
Нет ничего хуже руководителя, который постоянно думает: "быстрее самому сделать, чем объяснить, что и как".

Похоже договорились. Достигли взаимопонимания :-) Редко такое бывает в интернете :-)

162. tango 553 17.03.11 14:57 Сейчас в теме

(159) дополни пример оценкой Сталина как военачальника (программиста)
http://www.pokaianie.ru/article/stalin/read/8784

164. awk 745 17.03.11 15:03 Сейчас в теме

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

167. tango 553 17.03.11 15:04 Сейчас в теме

(164) сходи по ссылке и оспорь

168. awk 745 17.03.11 15:13 Сейчас в теме

(167) А я про что? РП - великий. Даже посредственных ведущих спецов. мог заставить работать отлично. А в связке с гениями (Жуков, Дзержинский и т.д.) - творил чудеса.

169. tango 553 17.03.11 15:18 Сейчас в теме

цитата по ссылке:
"Был ли И. Сталин военачальником? Этот факт демократы нет-нет, да и ставят под сомнение. "

ды вы, батенька, демократ :)

а вот за гения-дзе можно и ответить

170. awk 745 17.03.11 15:23 Сейчас в теме

(169) Вряд ли. Я анархист по убеждениям. Демократию - не переношу на дух, просто потому, что не считаю, что ответ на вопрос: "Сколько будет 2+2" должен решаться голосованием случайных личностей.

171. tango 553 17.03.11 15:24 Сейчас в теме

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

174. awk 745 17.03.11 15:36 Сейчас в теме

(169) Товарищ Дзе - создал одну из самых прочных границ в мире (и уникальную по структуре на тот момент).
(172) И что? Раб в Древней Греции мог быть гораздо образованней, чем гражданин. Это только подтверждает мое мнение.

175. tango 553 17.03.11 15:39 Сейчас в теме

(174) это нельзя считать проектом - заказчик и исполнитель не разделены, бюджет никто не считал. к тому же это миф (вспоминается чубыс).
**
а про демократию и не спорю. только вот задумался - какая же система подошла бы мне...
просто оспоривать способности Сталина как военачальника нет оснований

176. awk 745 17.03.11 15:41 Сейчас в теме

(175) Я отвечаю за слова, что Дзе(Дзержинский) - гениальный исполнитель.

178. tango 553 17.03.11 15:43 Сейчас в теме

+(176) ... геноцида русского народа. это тоже не проект. во всяком случае - пока - незавершенный.

180. vkr 17.03.11 15:48 Сейчас в теме

(174) Сериалов насмотрелись, да? :) Еще бы Берлинскую стену вспомнили... А кто там РП был, а ? :)

172. tango 553 17.03.11 15:25 Сейчас в теме

Вообще-то, в классической демократии (старые греки) рабы к голусуванню не допускались.

173. tango 553 17.03.11 15:25 Сейчас в теме

del1

179. btr 17.03.11 15:46 Сейчас в теме

Руководитель проектов должен очень хорошо разбираться в предметной области и в управлении проектами. Он может не очень хорошо разбираться в технологиях с помощью которых реализовывается проект, если ему есть на кого положиться в этом вопросе. Например, большинство успешных менеджеров проектов, внедряющих решения на 1С вполне смогут руководить проектами, которые реализовываются на .NET, Flex или AJAX, при условии, что они понимают автоматизируемую предметную область. Очень хорошей программист драйверов для управления роботами скорее всего вряд ли способен управлять проектом внедрения 1С или Навижн. Очень хороший менеджер веб-проекта не обязательно будет столь же хорошем менеджером разработки ММОРПГ или твердотельного моделирования.

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

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

А вот те, кто думают, что могут чему-то научиться у Ландау, Курчатова или Королева - питают наивные надежды. Будучи талантливыми визионерами и организаторами все эти люди были диктаторами и сторонники строгого разделения полномочий в подведомственных им учреждения. Если ты чертежник - не давай советов слесарю. Но внимательно его слушай. А если ты слесарь - делай то, что указано в чертеже, а если не выходит - ругай чертежника.

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

Те, кто руководит группами программистов знают это не по наслышке. Те, кто вырос из программистов в руководители еще лучше знает, что программисты не могут ему помочь лучше руководить.

182. Трактор 1299 17.03.11 15:59 Сейчас в теме

(179)

Очень хороший менеджер веб-проекта не обязательно будет столь же хорошем менеджером разработки ММОРПГ или твердотельного моделирования.
Но важно то, что сами навыки управления "платформонезависимы"

Ты действительно не видишь противоречия в своих словах?
Написание кода на 1С, на яве или на Си это механическая работа. Но руководитель "с улицы", не понимающий внутренних тонкостей производства, внутреннего взаимодействия тех же объектов в 1С и ограничений платформы, не сможет руководить. В лучшем случае будут вылазить ляпы вроде низкой производительности 1С или аварий вроде СШГЭС.

187. btr 17.03.11 16:41 Сейчас в теме

Трактор пишет:

Ты действительно не видишь противоречия в своих словах?
Написание кода на 1С, на яве или на Си это механическая работа. Но руководитель "с улицы", не понимающий внутренних тонкостей производства, внутреннего взаимодействия тех же объектов в 1С и ограничений платформы, не сможет руководить. В лучшем случае будут вылазить ляпы вроде низкой производительности 1С или аварий вроде СШГЭС.

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

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

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

Когда в явном требуется руководитель проекта, а не Team Leader или Senior Developer - подразумевается, что требуются именно организационные навыки. Умение общаться на одном языке с командой - приветствуется. Просто не во всех отраслях необходимые руководители выросли и созрели. Тогда они приходят со стороны, а в технике и жаргоне разбираются в процессе. Приходится, потому что гениальные девелоперы любят пощупать за нежные места и повешать лапшу на уши. Так же как гениальные прорабы, гениальные конструкторы, гениальные бухгалтера и прочие разнообразные гениальные специалисты, искренне удивляющиеся, зачем ими, такими гениальными, нужно руководить, и почему руководители всегда тупее их (в том, в чем они себя считают гениальными)

Есть даже масса книг на тему "как руководить гением" :) Жаль никто не взялся написать книгу "Я гений, где мир у моих ног?"
Надо будет взяться на досуге.

190. Трактор 1299 17.03.11 17:16 Сейчас в теме

(187) Ничего-то ты не понял. Я уж имена, исторический опыт привёл, а ты всё слова, слова.

Так же как гениальные прорабы, гениальные конструкторы, гениальные бухгалтера и прочие разнообразные гениальные специалисты, искренне удивляющиеся, зачем ими, такими гениальными, нужно руководить, и почему руководители всегда тупее их (в том, в чем они себя считают гениальными)

Да, есть, конечно, "звёзды", "нарциссы". Но такие встречаются редко, а в руководство лезут ещё реже. Потому что им выгоднее быть "звёздами", чем пинаемыми руклями. Ты редкий пример используешь как основной аргумент.

В Рарусе есть руководитель департамента разработки Кирилл Ширин. Это очень хороший руководитель и очень хороший программист. Думаю что мало кого из тут присутствующих можно поставить рядом с ним.

193. awk 745 17.03.11 17:26 Сейчас в теме

(190) Рарус в неком кругу - слово ругательное. Про руководство их не знаю...

195. tango 553 17.03.11 17:35 Сейчас в теме

+(193) и в довольно широком... при этом хороший РП, оказывается и хороший прогер...
может быть тут собака порылась в том, что продукт афилированного лица не может быть лучше продукта лица 1с?

198. awk 745 17.03.11 17:43 Сейчас в теме

(195) Мне Рарус предлагал работу, при этом ЗП за должность была в два раза ниже чем по городу. Угадайте куда были они посланы? Зато мной был сделан вывод о том кто может работать в данной компании при такой зарплатной политике.

201. Ish_2 1117 17.03.11 18:18 Сейчас в теме

(190) Примеры можно подобрать любые.
Давай рассмотрим пример , который льет воду на твою мельницу.
В романе Артура Хейли "Колеса" описан хозяин завода поставщика автокомплектующих (имя персонажа не помню).
Так вот он имел дома станок, на котором изготавливал пробные изделия. Зачем ?
Для него вопрос себестоимости изделия был вопросом жизни и смерти.
Деталь должна стоить меньше 10 долларов и точка !
И здесь он не доверял никому, никаким экспертам.

Теперь вопрос : РП должен быть программистом или нет ?

202. Трактор 1299 17.03.11 18:31 Сейчас в теме

(201)

Примеры можно подобрать любые.

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

Теперь вопрос : РП должен быть программистом или нет ?

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

203. Ish_2 1117 17.03.11 18:48 Сейчас в теме

(202) Хм.. Как обтекаемо !
Я гляжу ,мы поменялись местами :
Архитектуру системы(завода) может представить как раз менеджер , а не токарь (программист).
Но не общие соображения о структуре предприятия и стиль работы хозяина с подчиненными определяют успех бизнеса.
А конкретное жесткое условие : деталь должна стоить не больше 10 долларов !

И именно исходя из этого конкретного условия определяется успешность РП.
Поэтому конкретный ответ для конкретного случая - такой : РП должен быть программистом.

204. awk 745 17.03.11 18:57 Сейчас в теме

(202) А как же Сталин??? Он во второй мировой уж точно не был спецом - это был организатор связавший Фронт, Тыл и т.д. в одно целое.

205. Ish_2 1117 17.03.11 18:59 Сейчас в теме

(204) Отлично .
И мы получаем другой ответ : РП не должен быть программистом !

206. awk 745 17.03.11 19:09 Сейчас в теме

(205) Да плевать кем он еще может быть (РП), главное что бы руководить умел.

Я например на гитаре умею играть - это не мешает и не помогает мне полы мыть.

207. Ish_2 1117 17.03.11 19:14 Сейчас в теме

(206) Нет. Не так.
Вопрос : Должен ли РП быть программистом ? - не имеет смысла, если не определены условия проекта.

Назови конкретные условия - и я скажу "плевать" или "не плевать".

208. awk 745 17.03.11 19:42 Сейчас в теме

(207)
Если руководитель не может абстрагироваться от роли программиста и продолжает лезть в каждую мелочь - это вредит проекту. Он не доверяет команде. Если команда не доверяет руководителю - это то же плохо, но грамотный руководитель может это исправить не будучи программистом. У руководителя и у программиста разные задачи. Программист - должен писать код (отвечая на вопрос: "Как оно будет реализовано"). Руководитель должен руководить (отвечать на вопрос: "Когда и кем оно будет реализовано"). Тестировщик должен проверять правильность программы (отвечать на вопрос готово или нет).

Беда 1С - это и ее преимущество. 1С позволяет в короткие сроки, малыми ресурсами - создать более-менее работоспособные продукты. Отсюда создается впечатление, что программист - это все. Одно то, что тестирование в 1С практически отсутствует как класс (уже полгода ищем толкового тестировщика) - говорит само за себя.

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

Я не отрицаю что есть хорошие руководители из числа программистов, но программисту стать руководителем сложнее, нежели человеку который не писал код, а изучал непосредственно управление.

209. tango 553 17.03.11 19:49 Сейчас в теме

(208) сначала надо ответить на "Что - оно?" И тут мы возвращаемся к роли "архитектор", которую собеседники почему-то не принимают в оборот.
"полгода ищем толкового тестировщика" - цена вопроса?

Прикрепленные файлы:

210. awk 745 17.03.11 22:01 Сейчас в теме

(209) От 40 Питер... Приходящие и на 40 не тянут... Верхняя граница не определена...

215. tango 553 18.03.11 08:30 Сейчас в теме

(210) прикольно: цены на основные продукты на периферии (Ленинград - это вобще столица) даже выше москвы, а зарплаты ниже минимум в два раза.
Вопрос: Какого х? Тестировщик - это роль, за которой РП может (А)рхитектору - "да, мы это сделали". З/п тестера (его делегированная ответственность)- не меньше РП (меньше архитектора).

зы: ищите нормального тестера от 80

217. awk 745 18.03.11 08:51 Сейчас в теме

(215) В Питере зарплата РП от 45-180. Прогер - не превышает 50-60. Тестер не 1С - 20-50. С х..я платить больше?

218. Трактор 1299 18.03.11 09:19 Сейчас в теме

С х..я платить больше?

(217) знание бухгалтерии, нужные тестеру 1С, ничего не стоят?

220. awk 745 18.03.11 11:09 Сейчас в теме

(218) Бухгалтер (не главный) 20-40 - на рынке труда их завались. За 30 я недавно спокойно нанял гл. буха на два юр. лица. При этом со знанием бухгалтерии, а не 1С.

(219) Время тестировщика, обычно стоит меньше времени программиста. (с) "Тестирование программного обеспечения" Авторы: Сэм Карен, Джек Фолк, Енг Кек Нгуен.

Мы не против платить больше, но приходят дебилы.

Последний из кандидатов:

Резюме:
Образование:

СПбГУ, прикладная математика - процессы управления,
математик. системный программист
......

Ключевые навыки:

поддержка пользователей, обновление конфигурации, исправление кода,
написание кода

Из собеседования:

Что такое: 1С - не знает, SQL - не знает, тестирование - не знает.

Я такого не возьму и на 20.

228. Арчибальд 2712 18.03.11 12:40 Сейчас в теме

(220) http://forum.infostart.ru/forum1/topic38643/
Вот так-то :|

229. tango 553 18.03.11 12:47 Сейчас в теме

(228) сенькс за сцылку, а то бы и не узнал :)

230. awk 745 18.03.11 12:54 Сейчас в теме

(228)

Профессиональные обязанности:

- Консультирование пользователей по телефону;
- Обновление конфигураций ИБ;
- Выполнение заявок на доработку.

За это с учетом, что Москва - мало. Не забываем о том, что рынок труда в Москве и в Питере - это разный рынок. Последний коэффициент который у меня получился - 1.5 то есть ЗПМ = 1.5 * ЗПП. То есть по Питеру 46 - нормально таких хоть отбавляй.

Вот только мне не нужен человек:
- Консультирование пользователей по телефону;
- Выполнение заявок на доработку.

Мне нужен человек, который знает как искать ошибки и знающий, что программист 1С может исправить, а что нет. Средняя зп тестировщика у нас в отделе 60 + соц. пакет (15), так что по Московским меркам 90 + 22,5(не уверен, что 22.5 может та же 15 или меньше).

219. Арчибальд 2712 18.03.11 09:29 Сейчас в теме

(217) Тестирование -это исправление ошибок, следовательно, программирование - внесение ошибок © Э. Дейкстра
Автослесарь получает больше, чем автосборщик. И это правильно.

221. tango 553 18.03.11 11:10 Сейчас в теме

(217) пожимая плечами: ищите.
**\пять минут спустя
по ходу, ни х вам не нужен тестер

223. awk 745 18.03.11 11:31 Сейчас в теме

(221) Почему? Если человек имеет (показывает) диплом о том что он "системный программист", я предполагаю наличее у него хоть какого-то представления о базах данных и тестировании. Тем более, что придется ему тестировать не столько UI, сколько взаимодействие с внешними системами. Если человек заявляет, что он работал в отделе разработке 1С (7.7 и 8.Х) я предполагаю наличие у него понятий чем они отличаются. А по собеседованию выясняется, что он (она), тупо записывала обращения пользователей и передавала их программистам. Просьба рассказать об интересных проектах (работа/вуз) вводит человека в стопор.

P.S. Да и сиськи у нее были маленькие (что бы за них ей 35 в месяц платить (ее требование, по штату 40 минимум)) :))))

225. tango 553 18.03.11 11:56 Сейчас в теме

+(223) а что за лавочка торгует нынче такими дипломами?

226. Spartan 366 18.03.11 12:04 Сейчас в теме

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

250. awk 745 26.09.18 09:24 Сейчас в теме

(226) Угадал. Диплом был СПбГУ.

243. PiccaHut001 25.02.13 17:07 Сейчас в теме

не всякий программист может руководить, не всякий программист может программить.Каждому своё.
(223) дискриминировал девочку по размеру сисек, плохой, нехороший.

249. drkhaired 51 25.09.18 15:10 Сейчас в теме

(208)

Одно то, что тестирование в 1С практически отсутствует как класс

Это не потому, что 1С позволяет что то в короткие строки. За тестировщика вам никто не заплатит. Рынок альтруистов и бесплатной рабочей силы увы пуст.

212. MaxDavid 127 17.03.11 22:27 Сейчас в теме

awk пишет:

(202) А как же Сталин??? Он во второй мировой уж точно не был спецом - это был организатор связавший Фронт, Тыл и т.д. в одно целое.

Неверно. Во время гражданской войны Сталин был ответственным за поставки продовольствия на юге России, кроме того, руководил военными действиями при обороне Царицыно. То есть имел опыт и тыловой, и фронтовой; во всяком случае, представление и о том, и о другом имел. Возможно, именно это (знание фронтовой и тыловой специфики) позволило ему успешно организовать сопротивление вторжению.

213. awk 745 17.03.11 23:15 Сейчас в теме

(212) А еще банки грабил, то есть имел опыт обращения с оружием... :) На самом деле холивар: "Вот бы был руководитель спецом..." Я услышал из уст бухгалтера. Бухгалтер тот до сих пор бухгалтер, а его руководитель - до сих пор хозяин фирмы.

Кстати, видел я хозяев сидящих за прилавком. Оборот фирмы 20-40 Мр. в месяц, но развития нет. И на плаву потому, что нет конкурентов. А беда в том, что хозяин никак в кабинет перебраться не может.

216. tango 553 18.03.11 08:40 Сейчас в теме

(213) подробности мона вличку :) интерестна :)
**
пять минут спустя:
просто ему идея "делиться надо" - поперек горла

еще спустя:
к налику привык, наркота

188. YVolohov 726 17.03.11 16:49 Сейчас в теме

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

192. awk 745 17.03.11 17:23 Сейчас в теме

(188)

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

Это не путь к качественному продукту - это путь к погрязанию в мелочах. Пустая трата собственного времени и развал более-менее крупного проекта. Не побывав в "шкуре" руководителя этого не понять. Сложно представить как могут столкнуться интересы, что планирование - это львиная доля времени, что нужно и команду сохранить и руководство удовлетворить. Да много чего... Это надо пережить, что бы понять...

194. YVolohov 726 17.03.11 17:32 Сейчас в теме

(192) Я не говорю о контроле деталей всего проекта. Это дело тестировщиков. Но проект должен строится вокруг определенного ядра, на которое будет впоследствии наращиватся остальной функционал. Вот это ядро руководитель проекта, возможно в тесном сотрудничестве с наиболее опытными программистами, и должен разработать.

197. YVolohov 726 17.03.11 17:43 Сейчас в теме

(194)+ Существует правило 20/80, которое гласит что 20% усилий дают 80% результата а остальные 80% усилий лишь 20% результата. Так вот, применимо к 1С, 20% объектов конфигурации и алгоритмов будут использоваться конечным пользователем в 80% случаев. Вот их структуру и поведение и должны продумать до деталей наиболее опытные люди.

189. Арчибальд 2712 17.03.11 17:06 Сейчас в теме

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

Хорошим программистом можно стать только вовремя отойдя от пульта

И это ключевая позиция. Ведущий (хороший) программист, как правило, не пишет кода - если, конечно, он не единственный в проекте. Программист - это стиль мышления, а отнюдь не навыки применения некой платформы. И первое, о чем заботится программист, что является его компетенцией - предсказание поведения создаваемой системы при взаимодействии с окружающей средой - пользователями, руководителями бизнеса, кодировщиками ("программистами"). Т.е. решение управленческих задач входит в его компетенцию изначально. А деньги ему платят за то, чтобы то, что ему поручено, заработало в срок и с приемлемым качеством. Т.е. за успешное завершение проекта.
Другое дело, что не всякий хороший программист справится с достаточно крупным проектом, и для преодоления трудностей, возникающих при переходе количества в качество, следует учиться чисто управленческим технологиям. В первой статье речь как раз об этом.
ЗЫ В одном довольно крупном программном проекте я был ведущим исполнителем, не написав при этом ни строчки кода. Только в отладке заочно участвовал. В команде было на разных этапах от 3-х до 8 программистов.

191. YVolohov 726 17.03.11 17:20 Сейчас в теме

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

196. btr 17.03.11 17:42 Сейчас в теме

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

Поэтому для меня подобные споры - голая вкусовщина. Никто ничьих аргументов не принимает, потому что у самого звезда во лбу горит :)
Я и не против - дело хозяйское.

199. btr 17.03.11 17:44 Сейчас в теме

Да, я знаю очень много не слишком удачных руководителей, весьма успешных программистов. Больше чем сотню. Так что моя личная статистика успешных руководителей совсем не в пользу программистов, увы.

200. tango 553 17.03.11 17:47 Сейчас в теме

200

214. tango 553 18.03.11 08:26 Сейчас в теме

warden пишет:
взять на себя ответственность

ТЫ! ЗАПИСАЛСЯ в ЕДИНУЮРАСИЮ?
Ну, как бы это плакат, отвечать не обязательно, действует на зомбируемом уровне.

222. tango 553 18.03.11 11:16 Сейчас в теме

222!

224. tango 553 18.03.11 11:54 Сейчас в теме

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

227. awk 745 18.03.11 12:21 Сейчас в теме

(224) Я всегда пытаюсь найти в человеке плюсы... :)

У нас в отделе одни мужики - страдает эффективность работы. Нет мотивации по половому признаку. В гетерогенном коллективе срабатывает желание понравится (быть умнее) на подсознательном уровне. Это не я придумал - это если мне память не изменяет в америке в 20-х годах прошлого века установили. Точнее не помню - давно изучал.

231. tango 553 18.03.11 13:42 Сейчас в теме

Инвесторы признали свои вложения в российскую энергетику ошибкой, пишет газета «Ведомости».

Председатель совета директоров «Энел ОГК-5» на вопрос издания, согласился бы он инвестировать в российскую электроэнергетику, если бы знал, что произойдет с реформой отрасли, ответил цитатой из французского фильма: «Если бы я знал, то не пришел».

http://news.rambler.ru/9334009/

Прикрепленные файлы:

232. awk 745 18.03.11 13:51 Сейчас в теме

(231) Это к чему? Архитектором реформ точно не Чубайс был. Зато, как всегда, довел дело до конца и всех, кого мог, поимел. Снимаю перед ним шляпу, как перед гениальным аферистом.

234. tango 553 18.03.11 15:02 Сейчас в теме

гы. РП приватизации была именно эта рыжая сволочь.
развала энергетики - тоже она.
в нано разваливать нечего, только распиливать, поэтому теперь он в массовом сознании "1дминистраторов" - "спонсор"

236. tango 553 18.03.11 15:29 Сейчас в теме

Однако специалисты утверждают, что в срыве гособоронзаказа повинны не только конструкторы и руководители оборонных предприятий. Так, на совещании представителей уральских оборонно-промышленных предприятий (ОПК) директора заводов заявили о том, что контракты составлены таким образом, что производитель «всегда будет крайним». Оборонщики заявили, что по этим контрактам они делали ряд предложений, ни одно из которых не было учтено заказчиком.

Сложившаяся ситуация привела к тому, что работники предприятий российского оборонно-промышленного комплекса планируют массовые протесты против отсутствия госзаказов на этот год, сообщила на днях «Независимая газета». Акции пройдут 22 марта практически во всех регионах, где имеются предприятия по производству обычных вооружений, боеприпасов и спецхимии, а также перед зданием ведомства Минобороны.

http://news.rambler.ru/9339934/

237. awk 745 18.03.11 16:43 Сейчас в теме

(236) Я понимаю, что очень хочется доказать, что руководитель обязан быть спецом в области. Но это не так.

Пойдем те от обратного:
Если ты спец в области (программист), то почему ты не можешь объяснить человеку не программисту, что ты прав и надо делать так и в такие-то сроки, а не иначе? Почему руководитель должен понимать, а ты не должен уметь объяснять? А если ты спец и можешь объяснить, то какая тебе разница кто тобой руководит? Спец - ты. Делаешь проект - ты. Это не значит, что руководитель ничего не делает - у руководителя другие задачи.

241. MaxDavid 127 18.03.11 23:56 Сейчас в теме

(237)

Если ты спец в области (программист), то почему ты не можешь объяснить человеку не программисту, что ты прав и надо делать так и в такие-то сроки, а не иначе?

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

Почему руководитель должен понимать, а ты не должен уметь объяснять?

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

А если ты спец и можешь объяснить, то какая тебе разница кто тобой руководит? Спец - ты. Делаешь проект - ты. Это не значит, что руководитель ничего не делает - у руководителя другие задачи.

Какие? Задачи планировщика? Приходит РП на работу и объявляет - сегодня, мол, один спец разъясняет всё и вся заказчику, второй дорабатывает модуль, третий тестит то, что вчера написал первый - так, что ли?

Вообще, вспомнился Сирил Нортон Паркинсон - у него есть пример, как учитель вынужден проверять домашние работы учеников по совершенно другому предмету. Так вот, по прочтении ветки сложилось убеждение - руководитель, если он не спец в области, сможет успешно контролировать работу, но направлять ее успешно не сможет никогда.

Ответить

238. tango 553 18.03.11 17:02 Сейчас в теме

блин, еще один пониматель.
пипл, я сам не знаю чего хочу, ладно?

я не спец. я 1сник с корочкой "бухгалтер предприятия"
сижу на хелпдеске. объясняю человекам непрограммистам, что им надо делать, и почему получается так, а не так как им хочется. очень хочу спать, потому что кондишен плохо вентилит.
и мне пох все ваши руководители, своих хватает

239. cool.vlad4 2 18.03.11 17:16 Сейчас в теме

:D (238) как-то так и у меня...

Прикрепленные файлы:

240. tango 553 18.03.11 20:55 Сейчас в теме

ну, как-то так. только еще по телефону звонят

242. cool.vlad4 2 19.03.11 16:44 Сейчас в теме

Предыдущий пост напомнил мне когда-то прочитанные мной "Законы Паркинсона" http://lib.ru/DPEOPLE/PARKINSON/parklaws.txt...очень советую...помогает взглянуть трезво в том числе и на свою собственную организацию....

245. wunderland 203 12.03.13 13:41 Сейчас в теме

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

не совсем согласен - есть такая специальность "инженер-системотехник" так вот это, по моему, про него...

Сегодня руководит колхозом, завтра - авиапромом, послезавтра - пекарней. Результат известен.

знаем, знаем... и многим до сих пор пользуемся, потому что не то что лучше или хуже, а вообще ничего нового построить не смогли...
работать РМ должен, а не только руководить - с этим согласен
предметную область знать хорошо(программирование) - абсолютно согласен
РМ не профессия - тут не согласен. методикам управления проектами программистов не учат а на больших пректах без этого никак
Итого: статья спорная, а значит НЕ безполезная :). Автору "+". Пиши еще.

246. vs33 13.06.13 17:00 Сейчас в теме

Мне ни разу не встречались хорошие (читай: успешные) руководители проектов, которые ранее не были компетентными программистами. Все руководители проектов, которые влезли туда не имея указанного опыта - неадекватно думали, и как следствие - принимали ошибочные решения. К тому же они не умели держать баланс - между "хотелками" клиента и технической стороной в работе программистов, просто из-за незнания внутренних процессов программинга и программных механизмов конфигурации. А такой баланс в руководстве проектом - это 70% успеха. Хотя как руководители они чаще всего были великолепными. Поэтому только потомки программеров. Однозначно.
Практика критерий истины.

247. пользователь 28.12.14 20:07

Сообщение было скрыто модератором.

...

Для отправки сообщения требуется регистрация/авторизация

Автор:

Борис Балясников (bb1962)

Рейтинг: 993

Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.

Публикация:

№ 82673

Создание 14.03.11 19:46

Обновление 27.11.14 08:37

Статистика:

Просмотры 39482

Загрузки 0

Рейтинг 153

Комментарии 248

Характеристики:

Код открыт Да

Рубрики Компетенции и навыки

Кому Для всех

Тип файла Нет файла

Платформа Не имеет значения

Конфигурация Универсальные

Операционная система Не имеет значения

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)

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

См. также

Журнал

База знаний

Лаборатория

Анализ & Управление

Сопровождение 1С

Корпоративные решения

Обучение

Маркетплейс

Проектный офис

Мероприятия

Видеозаписи

Биржа заказов

Форум

Мерч

О компании