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

Публикация № 82673

Методология - Управление проектом

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Специальные предложения

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

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

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

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

И если человек которого волею судьбы поставили ответственным за сложную задачу - создать информационную систему, будет искать подсказку, то что ему поможет? Эта опозиционная отрыжка в виде попытки назвать руководителей бесполезными людьми или моя статья которая дает конкретные подсказки?
ShestakovVitaly; Anything; Spartan; +3 Ответить
59. Арчибальд 2711 16.03.11 07:47 Сейчас в теме
(45) А я, собственно, и не возражаю. Не бывает универсальных рецептов. И те два подхода, в 41 посте, я не противопоставлял, а сопоставлял. В реальности они вряд ли встречаются "в чистом виде". Если автоматизация начинается "с нуля", от арифмометров - первый подход должен превалировать. И совершенно другая ситуация, когда предстоит переход от ПУБ к КА. Там с большой вероятностью продуктивнее будет второй вариант.
248. drkhaired 50 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 992 15.03.11 06:11 Сейчас в теме
Alraune пишет:
Вроде, одна статья не противоречит другой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И если участники все заняты своими делами, тогда приступаю к выполнению сам, беру как правило те задачи, которые не потянуть не программистам, не консультантам. Это или конфликты или политика или улаживание противоречий между различными сторонами. Ну а когда время освобождается на старое и доброе программирование так что получается уйти в него с головой и не думать о течении проектов, ну это почти что праздник души ))
47. 15.03.11 18:32 Сейчас в теме
Ответственность штука сложная. На много сложнее взять на себя ответственность и выполнить обязательства любой ценой.
Гораздо проще мнить себя пупом земли, выполнять свои должностные инструкции, и дальше мониторов не заглядывать.
А управление это способность достигать результатов. Что для этого нужно? Да все!
Надо - глав.буха соблазнишь, надо - столы потаскаешь, в гостиницах без отопления поспишь, в самолетах полетаешь без передышки неделю, выслушаешь какой ты козел от 8 из 10 сотрудников, пару ночей без сна перебьешься перед закрытием проекта...
И все эти особенности как правило знают лишь те кому приходилось нюхать такое слово как ответственность, чтобы зарплату получали те кто кроме программирования в этой жизни ничего не хочет.
blackschool; RG-Soft; +2 Ответить
48. cool.vlad4 45 15.03.11 18:36 Сейчас в теме
"Наилучший руководитель - тот, о котором люди знают только, что он существует. Когда его работа выполнена, они скажут: ‘Мы сделали это сами’". ( Лао Цзы)
50. tango 487 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 487 16.03.11 09:22 Сейчас в теме
общепризнанные = признанные мной - позиция ожидаемая.

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

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

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


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

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


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

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

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

Во втором случае - клиент не знает, что хочет (где у него проблема) т.к. решил бы ее сам, а не обращался на сторону.
87. vkr 101 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 101 16.03.11 09:50 Сейчас в теме
(58) К Вашему пункту 2 ("Стадии роста...") :
6. Просветление. Прошедши сквозь стадии 1-5, и поняв, что более заняться нечем,
начинает блогосферную деятельность...
Sorry. "it was just business, not personal"
63. warden 101 16.03.11 09:44 Сейчас в теме
Написано разумно. Единственное, есть непонимание некоторых нюансов. Они не столь банальны, так что это простительно.
не надо организованность и дисциплину выдавать за отдельную профессию. Руководитель проекта - это не профессия, это скорее должность

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

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

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

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

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

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

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

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

Что еще хотелось бы добавить по поводу статьи - из собственного опыта - профессиональный управленец всегда найдет взаимопонимание с профессиональным программистом, чего, к сожалению, не скажешь наоборот. Наш брат даже с себе подобными иногда не может найти общего языка :D
68. tango 487 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 487 16.03.11 12:24 Сейчас в теме
(72) еще одна характерная примета: "вот обьяснить Вам, что значит "управлять""

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

Опять двадцать пять... Что такое "мокрое"? Пока не попробуешь, не поймешь, чем оно отличается от сухого. Попробуйте взять на себя ответственность за свою работу, за свою жизнь, за свои решения, поймете. Хотя, даже если сейчас и не поймете, с возрастом все равно придет.
89. tango 487 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. Арчибальд 2711 16.03.11 11:38 Сейчас в теме
Необходимо также четко осознавать границы нашей ответственности. Если при обсуждении с заказчиком оказывается, что он не ухватывает существенные моменты задачи, помните, что наша личная, поставленная нами самими цель - найти наилучший ответ - не обязательно означает заставить заказчика принять один лишь этот ответ. Любое размышление, которое допускает одну стратегию, обычно допускает несколько других стратегий, каждая из которых имеет свои достоинства и недостатки. Это всегда можно обобщить и получить удовлетворение от хорошо проделанной работы по изучению возможностей и обоснования своего выбора заказчику. Если, при полном понимании, заказчик делает выбор, который вам кажется глупым, то каким еще способом организация заказчика может чему-то научиться?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

См. также

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

Управление проектом Бесплатно (free)

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    9820    user809424    11    

Как стать исполнителем в проекте от Инфостарта

Управление командой Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    2096    alexandr.blinov    17    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    2503    MariaTemchina    22    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

Управление услугами и сервисом Управление бизнес-процессами (BPM) Управление прочее Управление проектом Бесплатно (free)

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    2352    MariaTemchina    4    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    34295    1СERP    79    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    4158    1c-intelligence    15    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

Из-за отсутствия грамотных правил разработки на этапе внедрения сильно усложняется работа по поддержке и развитию типовых доработанных конфигураций. О некоторых правилах и подходах в разработке, которые помогут специалистам сопровождать внедренное решение, на конференции Infostart Event 2019 Inception рассказал разработчик компании «Инвестиционная группа Абсолют» Алексей Степаненко.

08.06.2020    4714    stepan96    12    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    5296    sapervodichka    1    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    31023    1СERP    175    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    10617    MariaTemchina    33    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

На самом деле, переход рабочей жизни в онлайн обладает некоторым количеством плюсов. В частности хочется верить, что формальный контроль “отслеживаем кто сколько часов проработал, проверка, что сотрудники на месте и все чем-то заняты” заменится фактической отчетностью “по результатам”.

23.03.2020    5529    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    6120    VLikhobabin    44    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    31906    1СERP    189    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Waterflow Бесплатно (free)

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

23.01.2020    13879    MariaTemchina    8    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    6567    roman72    0    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6656    1c-intelligence    32    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

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

10.04.2017    31914    1СERP    107    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Бесплатно (free)

Очередной темой серии статей “20 мыслей об ИТ-проектах” будут требования к системе. По результатам голосования был вариант про карьеру проектных ИТ-специалистов, но ее я коснулся в докладе на Воронежском митапе, немного изменив и сделав акцент в сторону аналитиков. В ближайшем выпуске сделаю небольшую выдержку по теме.

14.10.2019    5949    chavalah    16    

Незакрытый проект на 1000 часов

Управление проектом Россия Бесплатно (free)

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    12215    ogroup    163    

Стратегия выживания в корпоративных войнах

Управление проектом Бесплатно (free)

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    9621    GSoft    15    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    42650    1СERP    231    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    11894    SergeyN    7    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

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

20.08.2019    8775    Arsen1986    7    

Быстрый старт: минимальный набор автоматизации типовых процессов

Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Автоматизация дает множество преимуществ бизнесу, но в то же время ее выгода может быть настолько несущественной, что процесс принесет компании больше убытков, чем прибыли. С чего начать эффективную автоматизацию, какие процессы стоит автоматизировать на первом этапе, а какие – лучше оставить на потом, рассказала руководитель разработки систем учета компании «Едадил» Екатерина Золотарева.

16.08.2019    8287    Hissin    18    

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

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

23.02.2017    27569    Gavrik    10    

Управление проектами по автоматизации бюджетирования

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    8005    SergeyN    1    

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов

Управление проектом Бесплатно (free)

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    6748    sbase    9    

Цифровая трансформация. Будущее учетных систем

Управление проектом Россия Бесплатно (free)

О цифровой трансформации слышали все, но немногие в этом разбираются. Что она собой представляет, какие несет изменения, на что надо обратить внимание айтишникам и 1С-никам, рассказал на конференции руководитель департамента автоматизации строительных организаций компании «Первый БИТ» Иван Аверьянов.

19.06.2019    10205    FB_10160810658600104    62    

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

Управление проектом Бесплатно (free)

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

17.06.2016    40132    raiml    37    

Риск - благородное дело!.. Часть первая

Управление проектом Бесплатно (free)

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    7554    MariaTemchina    8    

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения

Управление проектом Бесплатно (free)

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

31.05.2019    9044    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    11168    1c-intelligence    121    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    44641    CheBurator    64    

Устав писать Устав

Управление проектом Бесплатно (free)

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    7563    MariaTemchina    8    

Как сжать время?

Управление проектом Личная эффективность 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    8965    1c-intelligence    39    

Путь джедая в управлении проектами 1С: умение быть, а не казаться

Управление проектом Бесплатно (free)

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    11684    MariaTemchina    15    

Практика пуска склада продуктов питания Промо

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    36266    axxell    15    

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Управление проектом Бесплатно (free)

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    8231    chavalah    22    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    10001    MariaTemchina    20    

Бизнес, не горюй

Управление проектом Бесплатно (free)

Про цели автоматизации.

04.02.2019    10081    1c-intelligence    64    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

06.04.2015    37743    raiml    14    

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения

Управление проектом Бесплатно (free)

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

31.01.2019    8329    MariaTemchina    0    

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

Управление проектом Бесплатно (free)

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

14.01.2019    10137    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

Управление проектом Бесплатно (free)

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

10.01.2019    12843    chavalah    123    

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

Управление проектом Бесплатно (free)

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

16.11.2014    28770    raiml    46    

Где мы взяли флакон?

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

История появления и развития методики

26.12.2018    9843    1c-intelligence    7    

Озарение после прочтения макулатуры по проектному управлению

Управление проектом Бесплатно (free)

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    9819    MariaTemchina    24    

20 мыслей об ИТ-проектах, или 20 лет спустя.

Управление проектом Бесплатно (free)

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

09.12.2018    9180    chavalah    119    

Бизнес-консультант в малом и среднем-бизнесе. Кто это и зачем он нужен? Промо

Управление проектом УУ Бесплатно (free)

Я не буду здесь давать сухие определения, думаю, они никому не интересны. Бизнес-консультант – это тот самый человек, которого приглашают со стороны, чтобы он помог найти решение каких-то проблем. Также очевидно, что взгляд «со стороны» очень часто помогает выявить то, что вы никогда не обнаружите, будучи сотрудником компании. Я хочу с вами поговорить исключительно о бизнес-консультантах, которые работают с малым и средним бизнесом, т.к. с предприятиями с численностью сотрудников ориентировочно от 5 до 70 человек. Эта работа во многом отличается от того, что делают специалисты, которых привлекают в подобных случаях крупные компании. И, как раз, с этими нюансами есть смысл разобраться.

13.11.2014    27971    raiml    236    

Памятка руководителя: не играйте с деньгами

Управление проектом Личная эффективность Управление персоналом (HRM) Бесплатно (free)

Важная статья о персонале из цикла «Памятка руководителя»: здесь я планирую затронуть один из наиболее острых вопросов – деньги. А также развернуто ответить на некоторые комментарий читателей по двум прошлым статьям.

05.12.2018    17062    andironenko    128    

Шаг назад и ... шаг назад (классификация внутренних проектов)

Управление проектом Бесплатно (free)

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

03.12.2018    8716    capitan    26    

Белая и пушистая рецензия на Чёрную книгу Скрам

Управление проектом Бесплатно (free)

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

26.11.2018    10151    MariaTemchina    40