Исходные данные для проведения исследования
Исследовательская база
В качестве базы исследования использованы результаты вопроса участников тренинга «Решение сложных ситуаций». Тренинг проходит с 2009 года. Он ориентирован на партнеров фирмы 1С. Его задача помочь руководителям проекта найти выход в проблемных проектах по внедрению 1С.
Выводы собиралась в течение 4 лет – с 2009 по 2013. За это время в тренингах участвовало более 300 человек.
Разделение участников тренингов по функциональным обязанностям выглядело усредненно так:
(Здесь даны усредненные цифры, поскольку на каждом тренинге распределение участников незначительно менялось)
Большая часть участников тренингов были руководителями проектов по внедрению 1С, в том числе выполняли функции менеджера по продажам.
Порядка 20% были программистами и аналитиками, но периодически выполняли функции руководителей проектов.
Метод оценки
Выявление проблем, из-за которых проект по внедрению 1С может провалиться, проводилось путем опроса и перекрестных проверок качества ответов.
В начале каждого тренинга участники формулировали запрос на тренинг, что бы они хотели в итоге получить. Чаще всего о проблемах никто не говорил, и основной запрос был на тему послушать, услышать что-то новое, узнать, как решать сложные ситуации в проектах.
Затем следовал обмен опытом, где участники в группах выступали с докладом из области управления проекта, где делились своим реальным опытом. Это позволяло снять большинство теоретически вопросов «про послушать».
После завершения обмена опытом возникал логичный вопрос. Если все знают, как управлять проектами – писать качественное ТЗ, давать оценки, закладывать ному риска, договариваться и решать конфликты, то тогда в чем тогда возникают сложности в проектах.
После этого участники рассказывали конкретные ситуации из своей практики, которые они бы хотели разобрать на тренинге. На каждом тренинге формировался свой список из 10-15 ситуаций, над которыми мы работали все оставшееся время.
Примерно 80% сложных ситуаций относились к проектной стадии, т.е. когда уже выполнялись проектные работы, оставшиеся 20% относились к допроектной стадии – предпроектное обследование, продажа проекта, переговоры с сотрудниками потенциального клиента.
Почти 100% описанных участниками ситуаций относились у области «управление людьми в проекте» — переговоры, мотивация своей команды и команды заказчика, решение конфликтных ситуаций. Как правило, о технических проблемах связанных с программным или аппаратным обеспечением, участники почти никогда не говорили. Но в случаях, когда речь шла именно о технической стороне в итоге проблема чаще всего сводилась к двум вопросам:
- Как об этом сказать заказчику, чтобы не поставить проект под удар, и
- Как минимизировать свои потери, когда с заказчиком не удается достичь консенсуса
Фактически речь, так или иначе, шла о переговорах, т.е. области «управление людьми в проекте».
Три самые большие проблемы в проектах по внедрению 1С
Не попадание в ожидание заказчика.
Этот пункт абсолютный рекордсмен по числу собранных ситуаций – 50% случаев. В него входят все ситуации, когда с людьми из проектной команды заказчика не удается найти общий язык. Причем, это ситуации, в которых исполнитель пытается понять ситуацию, детально в ней разобраться, предложить компромисс, но, тем не менее, это сделать не удается.
В эту проблему входят такие ситуации, как:
- Невозможность договорится о цене проекта. Например, заказчик считает, что это дорого, ссылается не предложений другой компании. Аргументы про качество работ не помогают.
- Завышение, невыполнимые, противоречивые требования со стороны разных сотрудников заказчика. Например, руководитель согласовать бюджет и цель проекта, но когда стали вникать в детали, то поняли, что сотрудники заказчика имеют противоречивые ожидания от проекта.
- Конфликтные ситуации с конкретными сотрудниками заказчика по поводу технических решений в проектах, расхождения ожиданий, с которыми не получается договориться «по-хорошему». Сотрудник чрезмерно настаивает на своей позиции и не желает слушать аргументов.
- Проблемы «подразумевания», связанные со сдачей результата проекта, отдельных этапов. В ходе сдачи работ, оказывается, что заказчик подразумевал другое и возникает запрос на дополнительные работы без увеличения стоимости проекта.
- Появление новых участников в проекте, с которыми не удается достичь взаимопонимания.
Эти проблемы возникают в силу неверного определения интересов сотрудников заказчика проекта.
Влияние на проект очень высокое. Эта группа проблемных ситуаций способна растянуть календарный срок проекта в 2-3 раза, что приводит к кассовым разрывам компании поставщика и создает риск неуспешного закрытия проекта. Примерно 50-70% случаев сдвига платежей по проекту связаны с неквалифицированной отработкой ожиданий сотрудников заказчика.
Противодействие этой группе сложных ситуаций заключается в обязательной проработке интересов сотрудников заказчиков проекта. Экономически это не занимает дополнительного времени, но требует обучения и тренировки руководителя проекта навыку диагностики интересов. Ориентировочный срок формирования стабильного навыка диагностики интересов людей — два месяца.
Помочь в постановке навыка может тренинг по продажам или переговорам с условием обязательного внедрения навыка на практике. Примером такого инструмента является продукт «Мастер управления».
Отсутствие интереса сотрудников заказчика в проекте
Технически эта ситуация является разновидностью ситуации «не попадание в интерес заказчика», но в целом это отдельная группа ситуаций, в которых сотрудники включенные в проект не проявляют к нему никакого интереса и не исполняют по нему свои обязательства.
Ситуация возникает вследствие противоречия интересам сотрудников и неисполнения процессов формирования проектной группы. Иначе говоря, принудительно включили людей в состав рабочей группы проекта, а им это не нужно и даже мешает их работе.
В эту проблем входит ситуации:
- Вечной занятости сотрудников заказчика. Когда человек заинтересован в чем-то, он всегда найдет на это время. Вечная занятость один из признаков отсутствия интереса к теме.
- Частых задержек в процессе выполнения. Например, начали проверять остатки и отложили на неопределенный срок.
- Невнимательная работа – отнеслись к процессу формально, ради «галочки».
- Отсутствия инициативы, которую сотрудники проявляют к другим задачам.
Эта группа проблем возникает из-за неверного определения интересов участников проекта и отсутствия мероприятий по вовлечению сотрудников заказчика в проект.
Решения по предотвращению появления подобных проблем в проекте — как и в предыдущем пункте «не попадание в интересы заказчика».
Дополнительным инструментом является проведение командообразующих мероприятий в проекте, в ходе которых будет между командой исполнителя и заказчика будет установлен личный контакт. Это позволит выяснить личные интересы команды заказчика и вовлечь их в проект. Это решение значительно ускоряет динамику проекта. Но его внедрение целесообразно в крупных проектов (от 10 млн. руб.), бюджет которых позволяет потратить средства на подобное мероприятие.
Новые требования в ходе проекта
Эта проблема связана с появлением новых требований, в ходе выполнения работ по проекту, когда между заказчиком и исполнителем не возникает понимания на тему изменения границ, сроков и бюджета проекта.
В эту проблему входят ситуации:
- Появление новых требований, за которые заказчик не готов платить отдельно.
- Ошибки в проведении оценки проекта сотрудниками исполнителями и попытка переложить их на заказчика.
- Изменений бизнес среды заказчика, которые повлекли за собой необходимость в изменениях проекта без пересмотра его бюджета и сроков.
- Неоднозначные трактовки в документах группы «техническое задание», которые позволяют сторонам трактовать ожидаемый результат в свою сторону.
Проблемы возникают по трем причинам:
- Неверное определение интересов сотрудников заказчика. Это является корневой причиной, которая порождает следующую причину.
- Продукт автоматизации неосязаемый, поэтому ожидания по нему строятся только на основе опыта людей, участвующих в проекте. Если опыт неоднородный, то возникают проблемы с совместимостью ожиданий. Одни «хотят чуда, другие точного ТЗ».
- Отсутствия у сотрудников исполнителя опыта формализованного описания бизнес требований и достаточной для этого экспертизы в предметной области. Обычно в этом случае исполнитель описывает проект в технических терминах, которые слабо связаны с бизнес результатом проекта.
Решением данной группы проблемных ситуаций являются:
- Формирование навыка работы с интересами людей у руководителей проектов.
- Формирование у сотрудников, которые описывают требования заказчика навыка формализации бизнес требований
- Привлечение к оценке проекта сотрудников, которые имеют достаточную экспертизу по данной предметной области.
Заключение
Несмотря на высокую техническую составляющую ИТ решений, основанные проблемы в проектах по автоматизации возникают из-за недостаточной квалификации руководителей в области управления людьми и экспертизы в бизнесе заказчика.
Этому способствует отсутствие менеджерской подготовки ИТ руководителей. Чаще всего в ИТ руководят бывшие «технари», которые руководят по наитию.
В свою очередь потребность в обучении ИТ руководителей также отсутствует, поскольку основной проблемой ИТ рынка является дефицит квалифицированных специалистов. Поэтому заказчик, которому повезло найти квалифицированную команду, часто закрывает глаза на остальные проблемы в проекте.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2025 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Статья интересна тем что описывает не просто чьё-то видение. Но впечатление портят ошибки.
Я так понимаю статья — реклама?
потому как все кто терял клиентов знает что ситуации есть разные и вопрос попадания в желания клиента ВСЕГДА есть.
Оговорить все невозможно, а вот не внимательно отнестись к описанию процесса и включить в него описание подробное — задача предпроектного обследования.
Да и что называется невыполнение проекта — не доведение до логического конца? Так это не провал — а завершение проекта на на не конечной стадии. Кто-то допишет может быть. А фразы типа вставать на место клиента — по факту означает что надо дешево быстро и качественно. То есть не реально так как цель внедренца — не проект а прибыль компании за проект.
Да, Pavean, ошибки мой крест ) F7 не помогает
Нет, завязал с тренингами на эту тему.
Поделился, чтобы закрыть гештальт.
Вопрос не в определениях, что есть завершение проекта. Вопрос в кривой работе с людьми.
Это как кривое программирование, как ни манипулируй названиями, а кривые руки они и в Африке кривые руки.
обычно клиентам вот показываю в том смысле что реализовать мона все что угодно тока врядли оно клиенту надобно =)
В разделе статьи «Новые требования в ходе проекта» указаны всего три причины их возникновения. Я могу добавить четвертую:
— рост потребностей клиента по мере освоения полезного программного продукта.
У меня на любом проекте это происходит. И дело не в том, что что-то не описали изначально «нехорошие» аналитики. Видение любого человека меняется в процессе пройденного им пути.
(6) PAVI,
«рост потребностей клиента»
Да, согласен это происходит в большинстве случае и не зависит от качества предпроектного анализа. Настоящий интерес клиента проявляется через движение по проекту и сам человек понимает, что же он хотел на самом деле.
Работа с интересами клиентами , тот навык который слабо развит у РП и о котором идет речь в отчете, как раз помогает
прогнозировать расползание требований и минимизировать проблемы, связанные с появлением новых требований.
Я думаю выводы, сделанные автором далеко не однозначны. Что такое внедрение программного продукта? Для чего это делается? В первую очередь для того, чтобы:понять как мы работаем, иметь базу для прогнозирования своей деятельности и т.д. Есть ли заинтересованность в сотрудника работать в прозрачной системе учёта? Нет, и это понятно, каждый человек противиться контролю. Акцент как по мне расставлен здесь не верно.
И ещё, когда уже руководители поймут, что внедрение программного продукта должно ими контролироваться… Это вечный вопрос.
Я считаю что в раздел «Отсутствие интереса сотрудников заказчика в проекте» необходимо добавить еще одну причину — «Саботаж». Есть сотрудники преклонного возраста, которые против всего нового, не потому что оно плохое, а только потому что у них есть страх что они не смогут освоить новое ПО. К сожалению такие люди очень сильно тормозят внедрение, они пытаются похоронить проект в мелочах…
Есть всего лишь одна причина провала на проектах — слабый руководитель проекта.
Все остальные причины — их отмазки.
На полном серьезе.
(4) А «Доминикана» по какой причине не «взлетела»?
Все о одном и том же .. обсосано, облизано, обгрызано! Аж на целую статью! 🙂
(10) nurpoz, руководитель проекта от заказчика и исполнителя.
На мой взгляд: эта статья — еще один раз воду в ступе потолочь!
(14) lvictor58,
Это вечная тема, как «любовь и ненависть» 🙂
(11) TODD22, прошу прощения, дела клиентов, пусть даже прошлых, не комментирую.
> Этому способствует отсутствие менеджерской подготовки ИТ руководителей. Чаще всего в ИТ руководят бывшие «технари», которые руководят по наитию.
Так и лезут люди, ничего не умеющие делать, в руководители. Автор — это еще один пример.
Правильно заметили, писать грамотно не научился, а туда же — в руководители.
Уже отвечал таким:
(17) bb1962, не знаю, что вас так оскорбило, возможно на то есть причины.
По статистике с того же тренинга, примерно 1-2 человека на группу приходят показать свою значимость, которая является следствием недостатка умения влиять на людей, умения договариваться, а не гнуть пальцы.
Обычно так и уходят с чем пришли…
(17) bb1962,
Общая тенденция такая 🙂
Куда не плюнь везде бизнес-коучи, консультанты, руководители проектов, тренеры… Работать не хотят. Всем бы только учить и руководить 🙂
(19) TODD22, согласен.
Коучей развелось повсюду, лезут тут со своими советами ) А сами даже конфигуратор ни разу ни открыли, ну как таким людям можно верить вообще! 🙂
(20)
Я «конфигуратор» не имел ввиду. Как и программирование в целом.
(20) А вы «коуч» в какой области?
Я так понимаю раньше вы занимались «командообразованием». А сейчас в какой области работаете?
(22) TODD22, я завязал сейчас со всеми что относится к дисциплине управления и командообразования
и живу тихой мирной жизнью, не кого ни чему не учу.
(23)
Может расскажите как нибудь ? 🙂 Наверное как то иначе теперь смотрите на это… Всё же реальный опыт и ощущения интереснее теории…. 🙂
Вот это правильно 🙂
(24) TODD22, как нибудь расскажу )
Читал где-то про четыре состояния у сотрудников: не знают как выполнять работу, но хотят работать, не знают и не хотят, знают и хотят, знают и не хотят. В каждом случае рекомендации по мотивации разные… но в одном варианте только либо менять задачу, либо расставаться. В жизни, конечно, все сложнее, но общие понятия верные, мысленно применял к своему коллективу.
Думаю, с 90% вероятностью любой проект выполним, вопрос только в мотивации.
(10)(10)(19) TODD22,
А я бы отправил менеджеров среднего звена на обучение, и обязал проходить сертификацию.
Не умеют у нас люди ставить задачи подчиненным, а если еще сложить с не имением слушать других (своих руководителей, которые тоже не умеют ставить задачи), то получается полный бардак.
(27) -fox-,
некомпетентных сотрудников не только среди менеджеров много.
(28) TODD22,
Да, но если этот сотрудник обладает властью, бед он может причинить гораздо больше.
(29) -fox-,
Ну и? Что делать то будем? Работал в крупной холдинговой компании. 99% АУПа по знакомству. Из них 70% вообще без опыта аналогичной работы… и ничего как то холдинг работает. Деньги зарабатывает. Простому работяге тяжело…. сложно работать с некомпетентными самодурами. Но глядя по сторонам понимаю всем пофигу, все так работают…. по этому и нам коллега не стоит этим забивать себе голову.
Когда вас поставят руководить тогда проявите смекалку и покажете всем как надо работать, а так можно рассуждать и теоретизировать до бесконечности….
Эффективный управленец это куда больше чем человек с сертификатом или после спецкурсов. Тут нужно большое желание работать с людьми.
И чем больше с ними работаешь тем меньше хочется работать с людьми.
(30) TODD22,
Если ты работаешь рядовым сотрудником, то конечно изменить что-то сложно.
Но, если ты работаешь управленцем, хотя бы не забывать развиваться как управленец.
Как Вы считаете, должен руководитель уметь пользоваться «конфигуратором», если «Да», то для чего?
(32) -fox-, Руководитель должен как минимум очень хорошо знать работу своих подчинённых. Иначе как он ими будет руководить?
Может «уметь пользоваться конфигуратором» он должен не на уровне проф программиста но понимать, а что в нём делают должен.
(31) -fox-,
Пример можете привести того как управленец может развиваться как управленец ?
Не для этого люди идут в управленцы. Многие идут туда не по призванию, а так сказать по возможности. Если у человека есть возможность он ей пользуется.
Видел много примеров как люди ходили по разным тренингам, читали кучу литературы, ездили на зарубежные семинары и при этом оставались бестолковыми управленцами.
(33) TODD22,
Вы уже сами перечислили с помощью чего упр. может развиваться.
Есть люди, которым природой не дано руководить. Тут нужно спрашивать с тех, кто его поставил на эту должность.
(34) -fox-, Есть ещё один момент, по большому счёту все книги написаны теоретиками управления(учеными и т.д.). Так же как и большая часть тренингов проводится теми кто не имеет опыта руководящей работы(реальной работы). У них есть опыт проведения тренингов. И очень модно стало писать что я тренинговал: Сбербанк, Газпром, ООО «Бык-сервис» и какой нибудь «ШаражМонтажСтройГазТоргНефть». Ходить и пересказывать книги и чужие тренинги это одно… и не важно хоть 100 компаний обойди… И совсем другое быть эффективным управленцем. Что бы быть управленцем нужно очень много работать, а не читать теории и ходить по тренингам.
Практики очень редко преподают. Потому что человек умеет руководить, вот он этим и занимается с утра до вечера.
А у тренеров и коучей времени много, вот они с утра до вечера читают книжки и пересказывают друг другу тренинги и теории за деньги. Прошёл тренинг по продажам, всё сразу пишет «бизнес-тренер-по продажам». Прошёл по управлению сразу идут и начинают учить других как руководить не имея практического опыта.
Если где то реально преподают люди имеющие опыт практической управленческой работы это большая редкость.
Я когда учился у нас препода были кандидаты, профессоры и тд. Люди умные и очень интересные, писали книги, работы, двигали так сказать науку вперёд… И вот к нам пришёл препод у которого не было учёной степени… у него даже что интересно не было опыта преподавательской деятельности вообще до этого… Но зато он всю жизнь проработал в НИИ и КБ. Он собирал всякое эксперементальное оборудование для АЭС, вертолётов, самолётов, ракет и тд… Ну так вот наверное не надо объяснять у кого мы научились больше и у кого на парах было интереснее 🙂
А проффесура это хорошо… послушали пересказ теории которая по его мнению интереснее других и пошли зубрить формулы… но практических, нужных и толковых знаний ноль.
И кстати этот препод пользовался у профессуры неприрекаемым авторитетом 🙂
(35) TODD22,
Согласен. Самого в универе не хватало практических примеров, применения знаний (Но это я уже понял когда пришел на работу).
Есть люди, которые из управленцев идут в бизнес тренеры и из них получаются действительно грамотные преподаватели с большой практической базой.
(36) -fox-,
Я не сомневаюсь что такие где то есть. Но ещё не одного не видел 🙂
А вот «бизнес-тренеров» без практики, а только прошедших +100500 тренингов. Таких много встречал…
(37) TODD22,
Эту случаем не в Москве?
(26) Dimkasan, спасибо за комментарий.
Да, это похоже на «Ситуационное лидерство» Кэна Бланшара.
Да, согласен, такие модели не отражают всей глубины происходящего, они скорее дает хоть какой-то ориентир.
К сожалению, психика человека многомерный динамический объект, и любая типизация обречена, т.к. она лишь часть спектра.
Хотя глядя на поведение некоторых людей, порой возникает сомнение, что их психика многомерный динамический объект 🙂 Складывается ощущение, что там ровная прямая )
(10) nurpoz, Полностью согласен. Многое зависит от умения руководителя проекта наладить контакт с заказчиком.
(37) TODD22,
А вот «бизнес-тренеров» без практики, а только прошедших +100500 тренингов. Таких много встречал…
Да, это тенденция. В 80% бизнес-тренер — это выпускник педагогического ВУЗа. Ведет тренинги по продажам, хотя не умеет продавать, ведет тренинги по УП, хотя в проектах не был, ведет тренинги по лидерству, хотя сам работает на рядовой позиции.
А те полтора идиота с опытом, которых каким-то образом занесло в тренинги, теряются на фоне.
На мой взгляд — это все признаки зарождающегося рынка.
Кстати за последние три года рынок бизнес тренингов кардинально просел по объему.
хм.. ну я вот сейчас — РП со стороны Заказчика.
Проблемы не в людях — тут у нас порядок.
Проблемы — в попытках навязать за наши деньги разработчиками типовой функционал с минимальными докрутками. нас это не устраивает. Просто потому, что для эффективной работы — типовый решения не годятся. Они делают то что надо. Но — долго и неудобно! В ТП определена нужная функциональность. Расписывать в ТЗ все до мелочей подробно — ТЗ будет примерно толщиной в 500 страниц, ТЗ соответственно не было. Вот и выдавливаем из себя и из внедренцев раба по капле. Договориться удается и все делается, идем на компромиссы. Но как это все долго и нудно — просто капец… за это время сам бы написал все что надо 😉 Но мне теперь лень писать… в «коучи» пойду… 😉
(41)
Кстати за последние три года рынок бизнес тренингов кардинально просел по объему.
Мне кажется это вырождающийся рынок. «Наелись» люди тренингами эффективности, роста, лидерства, бизнеса и тд.
Я уже приводил пример в одной из тем. Работал в автосалоне. К начальнику отдела продаж постоянно кто то приходил и предлагал тренинги продаж.
Первое что делал нач. отдела это говорил: -Пройдёмте в выставочный зал и вы нам покажете как нужно продавать.
После этого 90% приходивших вставали и уходили обидевшись… Те 10% что ходили в зал особых результатов не показали.
Сейчас к выбору тренингов нужно подходить более серьёзно. Результаты нужно покупать а не бизнес теории из умных книг. Книги мы то же читаем.
Только вот беда что импортные теории из умных иностранных учебников, настолько иностранные что у нас не приживаются….
(42) CheBurator,
Ну вот, и ты туда же… скоро работать некому будет, все будут учить 🙂
Можно ещё и в «бизнес-консультанты» то же модное нынче направление 🙂
(44) не, не пойду 😉
буду играющим тренером в той области где что-то смыслю.. 😉
(43) TODD22,
Первое что делал нач. отдела это говорил: -Пройдёмте в выставочный зал и вы нам покажете как нужно продавать.
После этого 90% приходивших вставали и уходили обидевшись… Те 10% что ходили в зал особых результатов не показали.
Очень хорошо. Это работающий метод оценки тренера. Я так делал, когда покупал тренинги и со мной так делали, когда продавал.
Правда все равно, если сорри в автосалоне быдло работает, то даже умеющий продавать тренер проблему отсутствия желания учиться не решит.
TODD22, вы скорее всего если что-то читали, то очень плохой перевод или не очень хорошего автора. Это как иностранные книги по программированию на C++, перевод может убить книгу.
Например, Питер Друкер, «Практика менеджмента» 2009, очень сильная книга с хорошим переводом. Правда уже не продается.
..кто ж рыбные места-то выдает…
(43) TODD22,
Приживаются, только требуют серьезной локализации. Что русскому хорошо, то немцу смерть.
Все, что внедряют «как у них» работает через одно место. Головой никто не хочет думать, все хотят готовых рецептов и быстрых результатов. А в реальности нужны годы, к чему не многие готовы.
(46)
Например, Питер Друкер, «Практика менеджмента» 2009, очень сильная книга с хорошим переводом. Правда уже не продается.
Было дело и Друкера и Файоля читали…. 🙂
Книга она так и остаётся книгой… а практика есть практика. Если человек берёт книгу что бы овладеть навыком, получить знание это прекрасно.
Но получается интересная ситуация приходит кто то со стороны. Говорит вы здесь всё не правильно делаете и пересказывает Друкера за деньги….
(48) nurpoz,
Может оно и так… я больше сталкивался с тем что всё настолько абстрактно и теоретизировано… что читаешь и понимаешь… вот это круто, вот это сила мысли 🙂 А потом пытаешься что то применить на практике и понимаешь что как то оно или не так работает или вообще не работает. А иной раз вообще задаёшься вопросом человек который это писал в глаза то хотя бы видел то о чём пишет.
Для меня статья полезна. Недавно закончила свой первый проект, руководство которым осуществляла по наитию, и читая статью, понимаю, что мы столкнулись со всеми этими проблемами и вроде всё это уже теперь знаю, но этот опыт неструктурирован и необдуман до конца. Т.е. да, согласна, так и есть, а выводы какие? Эта статья полезна тем, что эти проблемы выведены «на бумагу» и уже точечно по каждой проблеме нужно будет обдумать как выстраивать работу с клиентом в будущем, чтоб на эти грабли не наступить. Если бы эти решения были в этой статье, то цены бы ей не было :))
(6) PAVI, Поделитесь, пожалуйста, как выходите из этой ситуации?
(50) AlbinaAAA, спасибо за комментарий.
Здесь как в описании алгоритма пузырьковой сортировки. Описание в несколько раз больше, чем код на языке программирования. Так и здесь, полное описание занимает 25 страниц и 60 дней тренировки для формирования навыка. А одна транзакция управления занимает 5-10 минут.
Если коротко — надо натренировать навык определения ведущего мотива. Это 70% всей дисциплины управления людьми.
(47) CheBurator,
Кто завязал с рыбалкой )
Одного не пойму, ну что тут можно обсуждать!? Автор прямо указал в аннотации:
То бишь, франчи! Ну кто во франчах работает: 1) рядовые программисты — студенты 3-5 курс/посредственности осуждающие 1С/неудачники, которые только и знают, что 1С и т.п. Тякучка с ними большая, и, если это девушка, то, В ОСНОВНОМ, она остается в этом франче, учит бухию, через 1-1.5 года замуж/декрет и вылет на 3 года из обоймы. Если парень, то через 1 год он уходит! 2) руководители, начальники и т.д. и т.п. — это уже те .. ну кто тут пишут.
В общем, как в армии, на пике пирамиды любых ВС — это солдат! И вот с кем тут, как говорится, идти в разведку? Я вас умоляю, даже гениальный руководитель, с детальнейшим ТЗ, не осилит ни один проект, ну если только сам все не выполнит. 🙂
(52)
Может пнёте в нужном направление? Подскажите что почитать, что посмотреть?
Есть наверное какая то методика тренировки этого навыка?
Людьми очень часто движет не то что они «задекларировали».
(49) TODD22,
Я со всем этим тоже столкнулся, поэтому и пишу.
Не применять на практике надо, а сначала подумать и придумать. Знаете, как в сказках детских, ну не говорится там напрямую делай раз-два, все завуалировано, метафорично. Кто без мозгов и/или невнимателен, не додумается.
Я могу пример про себя рассказать, который можно как аналогию использовать в этом контексте.
Когда я начинал работать самостоятельно, то не обладал какими-то фундаментальными знаниями в области управления проектами. Я закрывал проекты по наитию, со временем у меня выработались «приемчики», которые я использовал из раза в раз. А потом я вдруг встретил манифест agile, читаю и вижу, что описано то, что я делаю. Только я интуитивно это находил все по крупицам и у меня на это несколько лет ушло нащупывания способов шаг за шагом.
А теперь представим, чтобы было, если бы мне этот манифест попался раньше? Да ничего, я бы прочитал, подумал бы «ну да круто, чо!». Потом попробовал бы, обломался на первых проектах и забил бы. Я бы со спокойной совестью мог бы сказать: «ажайл не для нас, у нас это не работает» и был бы по своему прав.
И так не только с ажайлом. Есть еще некоторые методологии, которые считаются даже в мировой практике сложновнедряемыми, а я на них интуитивно вышел, просто работая и выискивая все время все более лучшие методы работы. Я про них только сейчас узнаю, оказывается мы повторяем то, что давным давно описано в книжках. Читаю про них сейчас, полезно, много времени экономят, кое-какие грабли позволяет обходить.
Но что толку про эти методологии читать ДО реальной практики? Только практика покажет, что работает у конкретного человека, а что нет. А уж от этого и плясать дальше.
(56) nurpoz,
Ну почему же… и теория нужна 🙂
Я не столько про подход говорю. Сколько про то что очень часто учат люди без практики.
(57) TODD22,
Согласен, немного перегнул )
Почему-то показалось, что пост был не в контексте обучения, а в контексте теорий.
Статья из серии 2*2=4. Непроверяемые, но красивые диаграммки, достаточно многих касающаяся тема, немножко общих слов, побольше воды и — вуаля, ещё одна ботва на ровном месте. Пользы — ноль, конкретики йок.
Поймите уже наконец, в наших условиях все теории, что отечественные, что западные либо восточные, выеденного яйца не стоят. Всё решает только и исключительно батькин кулак, царёв указ, длань руководящая итд. Т.е. волевой административный посыл. Если он есть и направлен в позитивно-конструктивную сторону, у вас и с тупыми юзверями, кривым софтом, лажовым ТЗ и неумелым РП всё взлетит. Потому что босс так сказал, и будут пахать, как ёжики. А протестующих — железными палками, лишением премий и тыды. А если боссу пофигу или неявно поперёк, то вы хоть упритесь, ничего не выйдет. Ну или если явно очерченного босса нет, и некому потерявших нюх в чувство приводить, тоже облом выйдет.
А разговоры, как сделать «главный кулак фирмы» своим союзником, имхо, совершенно не имеют отношения к тематике ИС, ибо это сплошь психология манипулирования.
(18) меня ничто не оскорбило, я просто констатирую факт:
«Так и лезут люди, ничего не умеющие делать, в руководители.»
Что касается тренингов, то ключевая фраза в самой статье:
«Большая часть участников тренингов были руководителями проектов по внедрению 1С, в том числе выполняли функции менеджера по продажам.»
Все сразу понятно, и кто пришел, и зачем, и с чем уйдут.
Менеджеры по продажам решили расширить ассортимент и начать продавать проекты.
Не согласен с 3 самой большой проблемой «Новые требование в ходе проекта», это не считаю вообще проблемой, а частью жизни проекта внедрения. Проект длиться длительный период, и за время внедрения ситуация меняется и не раз. Те внедренцы, которые говорят о таких причинах, просто не готовы к переменам в ходе проекта и это их минус.
«Не попали в ожидания заказчика» — ну это вообще не проекты были, а пытались продать любой ценой 1С.
«Отсутствие заинтересованности» — такое просто изначально закладывается в проекты, и является глобальной проблемой только для новичков, все остальные прогнозируют такое еще на начальном этапе проекта.
На мой взгляд все эти три пункта не являются большими проблемами при внедрении 1С, а выдумки начинающих или не совсем грамотных специалистов.
(61) alex_sh2008,
То же так подумал когда читал статью.
Вот то же не понял в чём проблема. Нормальное дело… когда в процессе требования меняются. И нужно сразу планировать. На первом этапе делаем работы № 1, 2, 3. Затем промежуточный этап. На котором либо реализуются новые «хотелки» если дальше не можем работать без них. Либо если работать можем выносим в отдельный этап. Вот в этом отдельном этапе уже делаем работы №4, 5, 6…
Есть правда хитрые заказчики которые начинают эти работы включать в первый этап. Но никак не хотят при этом увеличивать бюджет.
Но это уже отдельная тема для разговора…
(62) TODD22,
Мир полниться слухами. Большинство проектов по 1С не имели высокой эффективности, и заказчики исходят именно из этих соображений, и на начальном этапе пытаются охватить наиболее критичные направления, даже если это не совсем правильно.
(33) TODD22, у руководителя проектов должна быть очень хорошо развита эмпатия (способность посмотреть на проект глазами конечного пользователя, глубоко понять его потребности). Если этого нет, то никакие семинары и тренинги на тему управления не помогут, так и останется бестолковым руководителем, потому что главной проблемой такого руководителя всегда будет первая причина провала приведенная в данной статье, а именно «Не попадание в ожидание заказчика» .
(64) AlbinaAAA, Дак это проблема не проекта, а руководителя проекта. Для команды проекта может быть это и провальный проект, но в целом сам проект не провальный, его просто закончит другая команда. Очень часто сталкивался с таким, и самому приходилось вытаскивать проект из заведомо тупикового состояния.
(55) TODD22,
Есть наверное какая то методика тренировки этого навыка?
Любой тренинг по переговорам, а лучше по продажам, только обязательно с постренинговой поддержкой,
т.е. чтобы вы наработали навык и тренер проверил, что вы все правильно делаете.
По практике через 50 «отжиманий», т.е. попыток применения на практике методики, которую дают на тренинге
возникает устойчивый навык, который дает результат.
Если сходить только на тренинг и не «отжиматься» потом — деньги на ветер. Это как пресс качать. Можно
слушать инструктора сколько угодно, но пока качаться не начнешь, мышцы не вырастут.
Из тех кто делает это профессионально и кого лично видел в работе — Ася Барышева, Константин Дубровин.
(66)
возникает устойчивый навык, который дает результат.
Да вот столкнулся с тем что навык нужно как в поведение встроить. Что бы он использовался автоматически.
Я делаю так читаю книгу по переговорам(например) из неё выписываю себе полезные приёмы. Далее составляю себе что то типа краткой инструкции на основании полезных приёмов. В виде утверждений… Например «Я всегда выходя на переговоры буду делать …..».
Ну и затем уже читаю эту инструкцию каждый день 3 раза в течение месяца, в обязательном порядке. Ну и перед всеми важными да и не сильно важными переговорами всегда перечитываю….
Но вот что заметил… даже по прошествии нескольких месяцев. И даже после частого применения каких то приёмов навыком это не становится. Через месяц после того как перестаёшь за этим следить всё скатывается к прежней манере….
проблема в проектах всегда одна — это Клиент 🙂
(67) TODD22,
Я 5 лет назад встал на сноуборд. Мне нравится еврокарвинг.
Посмотрел кучу видеороликов как его делать, причем делал все, как там показано — нифига. Потом плюнул, нанял инструктора, он показал мне основы, стал пробовать, вроде чуть лучше, перестал падать каждый 5 метров, но все равно не получается.
Нанял другого инструктора )
Вобщем примерно через 50 правильных отжиманий у меня уже кое-что стало получаться. На это ушло около 6 месяцев, режим катания 1 раз в 1-2 недели.
Как ни крути нужно «отжиматься» и делать это правильно, получая промежуточный результат. Если бы я полгода кувыркался по склону, то скорее всего бы бросил нафиг эту затею. А сейчас понимаю, что все дело в правильной стойке и закатанной перекантовке. Как только тело запоминает эти движения, катание получается стабильно хорошее.
Может книжка у вас была правильная, но делали вы что-то не так, поэтому не получили промежуточного результата, который бы вас поддержал тренироваться дальше.
В применении к переговорам: сначала вы начинаете отслеживать свою результативность и первый сюрприз, оказывает 40% переговоров вы проигрываете, ну т.е. хотели одно, а вас убедили в другом, и вы потом плюетесь, ссылаетесь на «кривого заказчика» и все такое.
Потом вы начинаете разбираться со случаями, в которых не получилось выиграть. Оказывается там есть закономерность. Изменили стратегию, попробовали и точно, теперь вы проигрываете лишь 30% переговоров, прогресс. И так далее, пока вы не подниметесь до 95-99% выигранных переговоров, после которых дальнейшее улучшение не дает значимого результата.
(69)
Промежуточные результаты были.
Попробую применять какие нибудь приёмы более 50 раз… посмотрю станет навыком или нет.
(68) вообщем согласен. для меня клиент = исполнитель (внедренец, отсосер и т.п.)
(71) alex_sh2008,
А при чём тут статья дженералиста?
(73) TODD22, 1С задет тон проектов, и выдает рекомендации для партнеров, как они должны внедрять и сопровождать системы, и судя по статье 1С не очень то хорошо свою работу то делает,а уж что говорить про ее партнеров, отсюда и большая часть проблем на проектах.
(74) alex_sh2008,
А вы судите не по статье «бизнес — консультанта-дженералиста»(то есть Рамиля). А по своему опыту!
Мир намного более разнообразный чем чьё то субъективное мнение. И принимать его за истину было бы наивно…. К тому же если внимательно почитать статью то спорных моментов, притянутых за уши домыслов и откровенной ерунды в ней больше чем 90%.
В ней опять говорится о том что 1С плохая… но если быть объективным то проблем хватает в любом софте.
Приведите пример где обстоят дела иначе? Где есть супер ПО которое не нужно обновлять под постоянно меняющееся законодательство. Где взять ПО в котором не было бы багов?
Где взять ПО которое учитывало ВСЕ потребности бизнеса, что бы не требовала программиста…
И всё это по цене 1Ски…? 🙂
Провальные проекты это не вина вендора. Вендор продаёт софт «как есть». Вы всегда можете выбрать тот софт который больше подходит вам.
Вендору то же во многом не хватает опыта.
(75) TODD22, По своему опыту я ко всем системам отношусь одинаково, и считаю что клиент за ранее должен про все минусы и плюсы внедрения и сопровождения 1С знать, может поэтому в моей практике не выдвигались на первое место проблемы описанные выше, по сути и я, и заказчик заранее знали об появлении этих проблем.
(76) alex_sh2008,
Я об этом и говорю 🙂 Не надо валить всё на «кривую 1С». В любом софте огромное количество ошибок и проблем.
Понятно что это неприятно для пользователя и для того кто запускает софт.
Надо понимать что софт и автоматизация это очень сложная в техническом и методическом плане деятельность. И относится к этому нужно так же 🙂
Как к обычной пусть и сложной работе 🙂
(77) TODD22, Раз такого рода статьи появляются значит прецедентов очень много, которые в общем итоге сводятся к плохим программам и сопровождению именно самой 1С, а не какой то там фирмы франчайзи, которая на косячила, да и не один раз.
(78) alex_sh2008, Конечно много прецедентов 🙂
Но обычно в таких статьях мы читаем чей то субъективный опыт.
Интересно было бы узнать, велика ли доля тех респондентов, кто документировал требования, и какие причины провала самые популярные в этой группе.
У нас просто не привыкли софт рассматривать как средство производства — наравне с офисами, складами, менеджерами.
Отсюда зачастую и такое отношение к внедрениям.. и результаты…
а может главная беда это деньги? Точнее их отсутствие 🙂 И мотивация исполнителей проекта и конфликты интересов заказчик — исполнитель. Уберите деньги, оставьте «спортивное» программирование и будет счастье 🙂
Но «заказная» разработка ПО не может без денег, значит надо искать эффективный критерии оценки стоимости и перераспределения денег между участниками проекта.
А уже как следствие их поиска мы имеем различные способы коллективного размазывание ответственности — ТЗ, гибкие методики разработки, разбиение на этапы и т.д.
1. недостаточно квалификации исполнителя.
2. недостаточно мотивации заказчика.
остальное вторично.
В позапрошлом году на ИС отшумел образцовый проект «Доминикана» от 1с Бита.
Люди , собранные со всей России, в «прямом эфире» создавали некий небывалый программный продукт.
В команде даже был тренер по тимбилдингу ( как я понял , всех сплачивал и придумывал командные кричалки )
Прошел год , о «Доминикане» — ну слуху , ни духу.
Кто знает чем дело закончилось ?
Какая из 3 топ причин сработала ?
(80) сер1,
Точно не считал, но крайне редко попадался кто-то, не знающий о необходимости документирования требований. Скажем так, документирование требований звучало как «баян» )
(85) Посмотрел профиль автора. Ба !
Денис , а я ведь попал по адресу.
Так что там с «Доминиканой» ?
Конкретный пример проекта и Ваш анализ будут поинтереснее , чем тезисы статьи.
(86) Ish_2,
Прошу прощения, Ish_2, но уже писал, что клиентские проекты не обсуждаю.
Мне кажется ДОминикана в большей части была пиар акцией, нежели проектом разработки. типа как дом2, где строят любовь. Школота наверное уже не знает что ДОм1 сначала реально дом строил 🙂
(87) допускаю , что такой ответ единственно возможный и разумный в Вашем положении.
Участие в провальном проекте клиентуру не увеличивает.
Давайте забудем «Доминикану» и подойдем с другого бока.
Больше половины проектов действительно проваливается.
А раз так , то были бы интересны рассуждения тренера по тимбилдингу на тему «Как отползти из провального проекта ?» , можно назвать и скромнее , например «Пути отхода «. Возьметесь ?
(89) Ish_2,
У меня где то была книга на тему «Как выкручиваться из любых ситуаций» 🙂
Тут дело не в путях отхода. А в том как сделать так что бы провальный проект не бил по твоей репутации. И не возникало желание у других тебя подкалывать и расспрашивать.
Как пример «новая» военная форма. Как только Сердюкова сняли с поста. Так Юдашкин сразу стал на каждом углу кричать что он только дизайн рисовал и то что форма плохая он в этом не виноват 🙂
(90) TODD22,
Не нужно делать провальных проектов, если не уверен не берись!
(91) alex_sh2008,
Это в теории. На практике очень много нюансов 🙂
(92) TODD22, Нюансы есть всегда, даже в успешных проектах, есть куча минусов и плюсов, а если уж квалифицировали проект как провальный до грошь цена этому внедренцу, а что касается клиента, он все равно завершит этот проект, но у же с другими или самостоятельно.
(93),(90)Если ты не участвовал в провальных проектах , то что ты можешь сказать об успешных ?
Итак , ты уже попал. Любые советы : надо было то… надо было это.. не имеют никакого смысла. Хочешь , не хочешь — нужно выкручиваться и отвечать на вопросы.
Одну из возможных тактик , например , демонстрирует Денис в текущей теме по поводу «Доминиканы» — глухая несознанка. Дескать , не обсуждаю проекты клиентов и баста.
Возможно , такая тактика меньшее из зол.
Правда , в таком случае не избежать насмешек :
Как же это не обсуждаешь ? Еще как обсуждаешь проект клиента, даже рекламируешь !
Читаем в теме Дениса за 2013 г :
Чтобы разобраться с темой командообразования, понять, что нужно именно нам и что по этому поводу думают потенциальные участники проекта, мы провели вебинар «3 ключевых фактора образования эффективных команд».
И вот прошел год . Отвечать на вопрос : ну , как ? помог вебинар «3 ключевых фактора» ? — конечно , неохота. Сам разговор на эту тему — заведомый проигрыш. Поэтому я вполне понимаю Дениса.
Запишем себе в блокнот :
Способ № 1 «глухая несознанка».
Кто приведет другие тактики ?
(94) Ish_2,
Я приходил на провальные проекты, и на себе чувствовал все отрицательные эмоции персонала как программе, так и к себе как специалисту по внедрению , и всегда оставался виноватым, пока ситуацию не выравнивал в лучшую сторону, после этого отношение к проекту и программе менялось в положительную сторону.
Собрать круглый стол — заказчики, исполнители, руководители обоих сторон. Выяснить кто слабое звено, можно ли исправить ситуацию. Если нет, то просто закрыть проект на текущей стадии. Это всего лишь работа.
Если проблема в человеческом факторе, ее надо закрепить документально. Но сам документ не выход, а только подтверждение новых обязательство. Человеческие конфликты должны решаться людьми, а не бумажками.
Если проблема конфликта в изменившихся условиях (объемы работ или финансирование), то даже если условия не преодолимые на текущем этапе надо расстаться друзьями. Посоветовать заказчику других исполнителей (реально, а не в отместку). Велик шанс что потом это вернется сторицей — например вновь обратятся при улучшении финансовой ситуации, или просто не будут портить репутацию.
Когда менеджер молчит это значит что он облажался, ИМХО.