16
Обсуждение статей / Re: IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаем
« : 21 Февраля 2012, 20:14:22 »
Спасибо за пойманную неточность 
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
17
Методологии / Re: Как вы думаете, к какой методологии или идее относятся десять высказываний ниже?
« : 18 Февраля 2012, 01:09:23 »
Хорошо, что не "то ли ответ" 
Да, промежуточный ответ есть. Это действительно "Кайдзен"
Детали, как обычно, в развернутой статье
Да, промежуточный ответ есть. Это действительно "Кайдзен"
Детали, как обычно, в развернутой статье
18
Методологии / Re: Как вы думаете, к какой методологии или идее относятся десять высказываний ниже?
« : 11 Декабря 2011, 15:19:44 »А можно огласить цель опроса?
Можно, но в конце опроса. Если цель озвучивается сейчас, то все сразу дадут верный ответ
Так что, Саш, увы. Могу лишь сказать, что... нет... не могу
19
Методологии / Re: Как вы думаете, к какой методологии или идее относятся десять высказываний ниже?
« : 09 Декабря 2011, 18:14:51 »
Голосование уже не будет чистым, так что я воздержусь от высказывания
На самом деле я могу продолжить словарный ряд: идея, стандарт, методика, методология... итд
Подвох в том, что назови я как оно реально называется, то все поймут что и как искать... этож сообщество аналитиков, вооруженных интернетом... так что какое есть название... пусть будет.
Можно не комментировать. Главное - проголосовать
Вы не на выборах - вас не обманут
20
Методологии / Re: Как вы думаете, к какой методологии или идее относятся десять высказываний ниже?
« : 09 Декабря 2011, 14:26:08 »
Истины нет, правда у всех своя, а врать мы не можем
Потому и ответ будет максимально правдивым на наш взгляд. Мы еще пособираем голоса и будет все видно.
Очень хорошо, что вы это понимаете. Даже отлично! Так что тем более ваше особое мнение было бы интересно
Потому и ответ будет максимально правдивым на наш взгляд. Мы еще пособираем голоса и будет все видно.
Исходя из постановки вопроса в голосовании, то конечно "в списке возможных вариантов ответов".
Также интересно, как вы будете доказывать правильность своего ответа, если конечно подвох не заключается в том, что система из десяти высказываний противоречива и они не могут быть соединены вместе.
Очень хорошо, что вы это понимаете. Даже отлично! Так что тем более ваше особое мнение было бы интересно
21
Обсуждение статей / Re: Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах», 20 окт, Мск
« : 07 Декабря 2011, 04:08:48 »Эт точно, особенно когда за дело берутся непрофессионалы
Думаю, какая-нибудь профильная организация решила бы наши проблемы весьма легко, быстро и изящно...
А адресок с профессионалами не подскажете
))))))))
22
Системный Анализ и Требования / Re: Макеты интерфейсов + ГОСТ
« : 28 Июня 2011, 18:00:03 »
Ой Я не очень форумный человек, но тут, как настоящий консультант, отвечу историей и вопросом
Был у нас заказчик, который все оформлял по ГОСТу. И говорил об этом открыто и гордо, высоко подняв при этом голову. Ну ГОСТ и ГОСТ. Дошло дело до обследования. Прошу: Принесите ТЗ по ГОСТу, а я посмотрю по какому же ГОСТу вы пишите - по 19му или по 34му. Приносят бумажку на 3 странички... из которых одна титулка, а вторая оглавление и аннотация...
Я в шоке. Спрашиваю: это что? ТЗ по ГОСТу... Я говорю, что это очень интересно, но я ожидал несколько большего.
Вобщем, после разбирательств выяснилось, что имелся ввиду ГОСТ 2.105-95 "Единая система конструкторской документации. Общие требования к текстовым документам". Смакуем. не ГОСТ19 на ПО, не ГОСТ34 на АС, а ГОСТ на оформление
Теперь вопрос: что вы имеете ввиду "Документация, разрабатываемая в рамках проекта должна оформляться в соответствии с ГОСТ"? А то мало ли... наш заказчик был полугоскомпанией и такой перл
Я не очень форумный человек, но тут, как настоящий консультант, отвечу историей и вопросом Был у нас заказчик, который все оформлял по ГОСТу. И говорил об этом открыто и гордо, высоко подняв при этом голову. Ну ГОСТ и ГОСТ. Дошло дело до обследования. Прошу: Принесите ТЗ по ГОСТу, а я посмотрю по какому же ГОСТу вы пишите - по 19му или по 34му. Приносят бумажку на 3 странички... из которых одна титулка, а вторая оглавление и аннотация...
Я в шоке. Спрашиваю: это что? ТЗ по ГОСТу... Я говорю, что это очень интересно, но я ожидал несколько большего.
Вобщем, после разбирательств выяснилось, что имелся ввиду ГОСТ 2.105-95 "Единая система конструкторской документации. Общие требования к текстовым документам". Смакуем. не ГОСТ19 на ПО, не ГОСТ34 на АС, а ГОСТ на оформление
Теперь вопрос: что вы имеете ввиду "Документация, разрабатываемая в рамках проекта должна оформляться в соответствии с ГОСТ"? А то мало ли... наш заказчик был полугоскомпанией и такой перл
23
Обсуждение статей / Re: Использование Method Composer при описании сложных и нестандартных процессов
« : 27 Января 2010, 17:41:55 »
Я не часто пишу в форумах... и даже не знаю как реагировать на откровенное хамство.
Буду реагировать как врач на не очень здорового человека
Читать надо материал полностью или вообще не читать! Слева направа и сверху вниз. Включая каменты к статье. Тогда может все станет ясно
По поводу сама себе все опишет... Ой сколько видено самописного... мало не покажется... от половины самостоятельных документов хочется плакать, от другой смеяться. Иногда, даже хорошие хирурги не могут делать сами себе операцию на открытом сердце.
Еще создается ощущение, что ВАС RUP в детстве покусал и вы его боитесь
Берите любую методологию, любой процесс и вперед! Инструмент есть, мозги (видимо) тоже есть и опишите проектное НМО в виде сайта-портала.
По поводу ИМХО - вот и возьмитесь за это непростое дело. Как говорил товарищ К.Прутков: "нельзя объять необъятное"...
Буду реагировать как врач на не очень здорового человека
Читать надо материал полностью или вообще не читать! Слева направа и сверху вниз. Включая каменты к статье. Тогда может все станет ясно
По поводу сама себе все опишет... Ой сколько видено самописного... мало не покажется... от половины самостоятельных документов хочется плакать, от другой смеяться. Иногда, даже хорошие хирурги не могут делать сами себе операцию на открытом сердце.
Еще создается ощущение, что ВАС RUP в детстве покусал и вы его боитесь
Берите любую методологию, любой процесс и вперед! Инструмент есть, мозги (видимо) тоже есть и опишите проектное НМО в виде сайта-портала.
По поводу ИМХО - вот и возьмитесь за это непростое дело. Как говорил товарищ К.Прутков: "нельзя объять необъятное"...
24
Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...
« : 28 Июля 2009, 20:48:25 »
Ладно, еще секрет открою
Это все (включая ссылки) были рабочие материалы для книги. Я еще собираюсь сделать несколько эссе (выдрать материалов из книжки), но вот я пока не уверен, что она будет пользоваться спросом... Хотя, опять же, дискуссия говорит об обратном.
Возможно тема и верная
Это все (включая ссылки) были рабочие материалы для книги. Я еще собираюсь сделать несколько эссе (выдрать материалов из книжки), но вот я пока не уверен, что она будет пользоваться спросом... Хотя, опять же, дискуссия говорит об обратном.
Возможно тема и верная
25
Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...
« : 28 Июля 2009, 20:14:13 »
Ой сколько всего написано
Зря я все таки год не давал ходу данной зарисовке
Так как считал, что она может быть двояко истолкована, так как описывая негативное воздействие человеческого фактора на реальном примере я рискую как консультант потерять лицо в глазах читателей (все равно кто-нибудь, что-нибудь не так поймет).
Слава Богу, что что в сообществе аналитиков таких людей почти нет
Коллеги, хочу обратить еще раз внимание на мой первый пест в теме. История, поведанная в зарисовке не есть пример одного внедрения, а есть попытка обобщить, накопленный за 10 лет внедрений, опыт общения с __человеческим фактором__
То есть это совокупность негативных факторов, собранных в одном месте, связно описанных так, чтобы большинство специалистов\консультантов\внедренцев\заказчиков и прочих увидели в этой истории себя
...
Еще хочу заметить, что в статье нет рецептов "как сделать правильно", или вообще - в статье нет раздела выводов... он и не подразумевается, так как мне хотелось вызвать интерес и втянуть в дискуссию...
У меня есть предложение попытаться вернуться к человеческому фактору, возможно у вас есть примеры, сверх моих, когда что-то и как-то упиралось в этот человеческий фактор (может есть истории из жизни?)
Когда то, еще будучи студентом, мне попалась книга по педагогике... Очень неформатная книга. Она представлена в виде мемуаров, где автор сначала описывал ситуацию, а потом разбирал ее "по косточкам" и говорил что и почему было не так.
Мне очень понравился данный формат изложения.
По результатам данного форума мне бы хотелось выпустить уже не эссе, а статью (расширенную и дополненную), которая бы строилась по шаблону:
1. Описание фактора
1.1 Рациональное объяснение как избежать подобного риска, как его снизить
1.1.1 Контр пример (из реальной же практики). Как это было успешно решено, или описание ситуации, когда этот фактор не оказал влияния
Товарищ Boatman почти раскусил мою идею
Теперь попробую дать ответы на некоторые сообщения:
Выше уже все сказано.
А задеть автора очень сложно. Хотя, скажу по-другому: автора можно попытаться задеть и даже скомпромитировать, но только во благо дискуссии
В реальной практике внедрения человеческий фактор играет ключевую роль при выборе стратегии внедрения. А если посмотреть вглубь, то оказывается, что человеческий фактор (он же менталитет) складывается из:
1. сектора рынка (банкинг, софтверная компания, телеком, отраслевая компания (нефтянка, металлургия), ОБОРОНКА)
каждый из факторов влияет на план (так как менталитет в разных секторах разный)
2. размер компании
чем меньше размер компании, тем менее формализованные методы в ней используются
3. РЕГИОН внедрения (или, если хотите, национальный менталитет)
Например, есть регионы, где очень большое уважение к старшим, даже если этот старший и старше-то на 2 дня
Если в такой проект с нашей стороны пойдет молодой специалист, то его просто не будут слушать (мальчишка, что с него взять)
И так далее и тому подобное. То есть, выбирая план работ (еще до подписания контракта) выбирается некая стратегия действий исходя из вышесказанного.
2. Я бы сказал по-другому - пока стоимость нефти или газа такова, что можно нагнать толпу неэффективных прапорщиков (привет, Юра), то это так и будет. На самом деле это проблема всех отраслевых компаний, в которых отдел ИТ- вечный проситель денег, а софт, внедряемый в основное подразделение (в бизнес) вечно виснет. Вот бизнес время от времени хочет как то улучшить прозрачность отдела ИТ, уменьшить количество багов... итд. И выделяет с барского плеча деньги на проект.
Причем, не всегда подраспильных.
2а Еще мысль-ремарка. Иногда бывают субподрядные проекты, в которых цели ставит генподрядчик. В таких проектах человеческий фактор может и за 100% выползти
3,4 ну история так и показана
ок
5. Тут интереснее
- "Заказчик мягко намекнул, что процессы ему выстраивать не надо." - в чем проблема, денег пожалели?
Возвращаемся к рыночному разделению компаний. Если проект относится к оборонке, то, в 99% случаев есть все нормативные документы... и общие положения, и положения о ролях, и регламенты. И в таких проектах нужно взять и сделать как написано.
Такой заказчик не всегде хочет платить денег за глубокое предобследование и выстраивание процессов.
Да, может и денег пожалеть.
Если провести аналогию с корпоративной культурой, то она есть в любой компании. Отсутсвие культуры - тоже культура
- "Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать" - надеюсь, его заставили положить эти процессы на стол в виде диаграмм, утвержденных регламенов и инструкций и доказательств того, что эти регламенты исполняются?
Что называется, не будем переходить грани светского разговора
В большинстве случаев, если заказчик говорит, что у него есть ФОРМАЛИЗОВАННЫЙ процесс, то мы просим его показать.
- "Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”." - иными словами очень хотелось заработать (не до жиру), по этому пришлось идти в проект на условиях заказчика (сам так попадал).
Даже не знаю, что написать...
Наверное, кому-то и не нужны. А так, вообще, это очень сильный аргумент со стороны заказчика.
Лично для себя я готов сделать многое для заказчика, если это не противоречит в дальней перспективе _ЕГО_ же интересам. Классический вопрос: если человек стоит с завязанными глазами перед пропастью и хочет сделать шаг вперед... разрешу я ему это или нет?
- "Пришлось взять расписку об ответственности за неуспех и приступить" - это хороший вариант для зарабатывания деннег. Для пользы дальнейшего процесса можно было грузить обязательствами "обязательно есть то, что заказывали, что заказывали четко задокументировать в спецификации".
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.
Ой! А как можно по-другому?
Роль расписки вполне играет _ПИЛОТНЫЙ_ проект
6-6.4
Золотые слова. Всем бы заказчикам в уши. На практике, внедрение новой системы взамен существующей (тем более если разработчики, ее поддерживающие являются сотрудниками компании), всегда сопровождается сложностями. Договор в этом случае прикрывает нас, но не гарантирует отсутствие человеческого фактора
6.5
Чтож вас так на бюджете заклинило
Ну нету в этом гипотетическом примере откатов. Говорю как автор эссе... не подразумевалось там такого фатора.
Есть хороший анекдот про гребцов... Надо будет премировать менеджеров и уволить за неудачу админа для остарски...
А если без шуток, то количество систем внедренных на бумаге слиишком велико, чтобы об этом не говорить.
Какие следаны выводы автором:
И тут не все просто. Помимо формальных связей (начальник - подчиненный) есть (и еще как есть) неформальные (брат, сват, родственник, сестра, жена), которые могут вести далеко __наверх__. Придумать пряники и кнуты для такого специалиста, который является в равной степени некомпетентным и бессмертным очень сложно...
Тут я открыт для обсуждения особенно. Может у кого есть способы воздействия на подобных персонажей (варианты устранения родственников не рассматриваются).
И прошу отметить, что ЭТОТ человеческий фактор НЕ ВИДЕН до заключения контракта... Мало того, он даже проявится в проекте не сразу... Вот в моей истории были примеры компаний, где запрещалось на работу брать родственников... Но их было посчитать по пальцам одной руки (руки трехпалого ящера)
Может на стадии подписания договора экстрасенсов приглашать? Не знаю...
Какие сделаны выводы мной:
Опять бюджет
Хочу чтоб был учтен фактор неформальных связей. И фактор выполнения проекта на подряде.
В остальном вопросов нет. Такая точка зрения имеет место быть и бывает.
Уф...
Дальше отвечу телеграфно. Цитировать очень неудобно
"идти ли в проект, если видишь, что он закончится не очень успешно, но деньги заплятят" - это тема отдельного разговора и на этот вопрос статья не отвечает (расклад по вопросу не ясен).
Иногда бывают непопильные проекты.
Всегда неясно будет проект успешным или нет.
Никто заранее не знает что и как будет....
В том, что сказано далее все верно:
Делать сразу промышленное внедрение с закрытыми глазами в рамках предприятия (самоубийство чистой воды)
Для этого есть пилотные проекты (пилотный проект, подобно НИОКР, подразумевает как положительный, так и отрицательный исход)
И только после "пилота" все принимается опытно-промышленную и потом в промышленную эксплуатацию. Тут все верно.
(есть же масса методов внедрения: горизонтальные, вертикальные... итд)
В развитие темы и для подолжения данной темы дам ссылки (на дополнительную критику):
1. Презентация с конференции Training Labs 2008 http://cmcons.com/presentation/tl_cc_cq/
Там как раз есть тема про типы внедрения
2. Человеческий фактор в обучении при внедрении http://cmcons.com/articles/course/trainings_strategy/
3. Тоже эссе на тему как правильно внедрить http://cmcons.com/articles/analitika/cool_deploy/
Вроде все.
Спасибо за пост. Готов при доработке данной статьи взять в соавторы
Зря я все таки год не давал ходу данной зарисовке
Так как считал, что она может быть двояко истолкована, так как описывая негативное воздействие человеческого фактора на реальном примере я рискую как консультант потерять лицо в глазах читателей (все равно кто-нибудь, что-нибудь не так поймет).Слава Богу, что что в сообществе аналитиков таких людей почти нет
Коллеги, хочу обратить еще раз внимание на мой первый пест в теме. История, поведанная в зарисовке не есть пример одного внедрения, а есть попытка обобщить, накопленный за 10 лет внедрений, опыт общения с __человеческим фактором__
То есть это совокупность негативных факторов, собранных в одном месте, связно описанных так, чтобы большинство специалистов\консультантов\внедренцев\заказчиков и прочих увидели в этой истории себя
...Еще хочу заметить, что в статье нет рецептов "как сделать правильно", или вообще - в статье нет раздела выводов... он и не подразумевается, так как мне хотелось вызвать интерес и втянуть в дискуссию...
У меня есть предложение попытаться вернуться к человеческому фактору, возможно у вас есть примеры, сверх моих, когда что-то и как-то упиралось в этот человеческий фактор (может есть истории из жизни?)
Когда то, еще будучи студентом, мне попалась книга по педагогике... Очень неформатная книга. Она представлена в виде мемуаров, где автор сначала описывал ситуацию, а потом разбирал ее "по косточкам" и говорил что и почему было не так.
Мне очень понравился данный формат изложения.
По результатам данного форума мне бы хотелось выпустить уже не эссе, а статью (расширенную и дополненную), которая бы строилась по шаблону:
1. Описание фактора
1.1 Рациональное объяснение как избежать подобного риска, как его снизить
1.1.1 Контр пример (из реальной же практики). Как это было успешно решено, или описание ситуации, когда этот фактор не оказал влияния
Товарищ Boatman почти раскусил мою идею
Теперь попробую дать ответы на некоторые сообщения:
Ситуация очень сильно перекликается с проблемами в моих проектах.
Хочу предложить уточнение: дело в той стороне человечекого и управленческого фактора, которая касается выстраивания отношений по итогам разрешения конфликта интересов.
Ниже представлены
- мое представление процесса внедрения в каком-то приближении;
- критика по ходу процесса внедрения, описанного в статье - разбор по пунктам. Я заранее приношу извинения, если задену автора. Я сам внедренец, все описанные проблемы и ситуации испытал на своей шкуре и точно так же прогибался в отношениях с заказчиком. И не факт, что это не повторится, так как дело не только в умении, но и в реальной силе позиции.
- И дальше хотелось бы обсудить варианты, как сделать лучше.
Выше уже все сказано.
А задеть автора очень сложно. Хотя, скажу по-другому: автора можно попытаться задеть и даже скомпромитировать, но только во благо дискуссии
Согласен с логикой на все 100%. Имея за плечами не один десяток проектов по внедрению могу сказать, что данный набор шагов верный и правильный. Только есть одно "но" - для достижения цели можно пользоваться разными методами и подходы будут разными.
Какие этапы необходимо пройти, чтобы было все ОК:
1. - определить ЗС (заинтересованные строны, их потребности и интересы, включая иррациональные)
2. - определить решаемую проблему (что хотят купить)
2а - определить целевое назначение системы (цели и показатели).
3. - определить решение, включая плетки и пряники, согласующие интересы ЗС
4. - определить цену вопроса: во что это все выльется не только по деньгам, но и по организационно-технической подготовке
5. - подписать заказчика на цену вопроса, включая его обязанности касательно каждой работы по плану
6. - работать по плану, в том числе:
6.1. -- настроить и пуско-наладить ПО
6.2. -- написать и утвердить инструкции и регламенты (второе очень важно)
6.3. -- обучить людей
6.4. -- прогнать их через опытную эксплуатацию
6.5. -- перевестись в промышленную, включая официальный ввод регламентов, при этом, если одна система заменяет другую сломать старую систему напрочь (стереть, отформатировать
В реальной практике внедрения человеческий фактор играет ключевую роль при выборе стратегии внедрения. А если посмотреть вглубь, то оказывается, что человеческий фактор (он же менталитет) складывается из:
1. сектора рынка (банкинг, софтверная компания, телеком, отраслевая компания (нефтянка, металлургия), ОБОРОНКА)
каждый из факторов влияет на план (так как менталитет в разных секторах разный)
2. размер компании
чем меньше размер компании, тем менее формализованные методы в ней используются
3. РЕГИОН внедрения (или, если хотите, национальный менталитет)
Например, есть регионы, где очень большое уважение к старшим, даже если этот старший и старше-то на 2 дня
Если в такой проект с нашей стороны пойдет молодой специалист, то его просто не будут слушать (мальчишка, что с него взять)
И так далее и тому подобное. То есть, выбирая план работ (еще до подписания контракта) выбирается некая стратегия действий исходя из вышесказанного.
Попробую по пунктам
Теперь посмотрим, что сбойнуло и на каких этапах:
1. Вроде, ЗС определили, точнее по тексту статьи не скажешь, но думаю там проблем нет.
2. Проблемы описаны. Немного смущает то, что "сама компания сверхуспешна, что позволяет бизнесу смотреть сквозь пальцы на чрезмерные издержки отдела ИТ."
Когда деньги текут рекой, инструментом является лопата, а не калькулятор. (с) Мы наблюдаем риск преврашения проекта в распил бюджета. Но это всего лишь риск.
2а. О целевом назначении не сказано - это настораживает. Один из основных рисков данного проекта.
3. Решение определили не очень... Ни плеток ни пряников и, в первую очередь для ЛПР. И это видно на седующем этапе.
4. Я думаю, смету посчитали - это не проблема, а вот требования к заказчику определили не до конца.
5. Здесь стали видны проблемы предыдущих 2х этапов:
- "Заказчик мягко намекнул, что процессы ему выстраивать не надо." - в чем проблема, денег пожалели?
- "Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать" - надеюсь, его заставили положить эти процессы на стол в виде диаграмм, утвержденных регламенов и инструкций и доказательств того, что эти регламенты исполняются?
- "Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”." - иными словами очень хотелось заработать (не до жиру), по этому пришлось идти в проект на условиях заказчика (сам так попадал).
- "Пришлось взять расписку об ответственности за неуспех и приступить" - это хороший вариант для зарабатывания деннег. Для пользы дальнейшего процесса можно было грузить обязательствами "обязательно есть то, что заказывали, что заказывали четко задокументировать в спецификации".
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.
2. Я бы сказал по-другому - пока стоимость нефти или газа такова, что можно нагнать толпу неэффективных прапорщиков (привет, Юра), то это так и будет. На самом деле это проблема всех отраслевых компаний, в которых отдел ИТ- вечный проситель денег, а софт, внедряемый в основное подразделение (в бизнес) вечно виснет. Вот бизнес время от времени хочет как то улучшить прозрачность отдела ИТ, уменьшить количество багов... итд. И выделяет с барского плеча деньги на проект.
Причем, не всегда подраспильных.
2а Еще мысль-ремарка. Иногда бывают субподрядные проекты, в которых цели ставит генподрядчик. В таких проектах человеческий фактор может и за 100% выползти
3,4 ну история так и показана
ок
5. Тут интереснее
- "Заказчик мягко намекнул, что процессы ему выстраивать не надо." - в чем проблема, денег пожалели?
Возвращаемся к рыночному разделению компаний. Если проект относится к оборонке, то, в 99% случаев есть все нормативные документы... и общие положения, и положения о ролях, и регламенты. И в таких проектах нужно взять и сделать как написано.
Такой заказчик не всегде хочет платить денег за глубокое предобследование и выстраивание процессов.
Да, может и денег пожалеть.
Если провести аналогию с корпоративной культурой, то она есть в любой компании. Отсутсвие культуры - тоже культура
- "Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать" - надеюсь, его заставили положить эти процессы на стол в виде диаграмм, утвержденных регламенов и инструкций и доказательств того, что эти регламенты исполняются?
Что называется, не будем переходить грани светского разговора
В большинстве случаев, если заказчик говорит, что у него есть ФОРМАЛИЗОВАННЫЙ процесс, то мы просим его показать.
- "Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”." - иными словами очень хотелось заработать (не до жиру), по этому пришлось идти в проект на условиях заказчика (сам так попадал).
Даже не знаю, что написать...
Наверное, кому-то и не нужны. А так, вообще, это очень сильный аргумент со стороны заказчика.
Лично для себя я готов сделать многое для заказчика, если это не противоречит в дальней перспективе _ЕГО_ же интересам. Классический вопрос: если человек стоит с завязанными глазами перед пропастью и хочет сделать шаг вперед... разрешу я ему это или нет?
- "Пришлось взять расписку об ответственности за неуспех и приступить" - это хороший вариант для зарабатывания деннег. Для пользы дальнейшего процесса можно было грузить обязательствами "обязательно есть то, что заказывали, что заказывали четко задокументировать в спецификации".
И здесь же всплыло отсутствие целевого наначения системы (риск реализован): основных достигаемых показателей. Неквязка между целевым назначением и более низкоуровневыми требованиями могла бы стать аргументом для заказчика.
Ой! А как можно по-другому?
Роль расписки вполне играет _ПИЛОТНЫЙ_ проект
6-6.4
Золотые слова. Всем бы заказчикам в уши. На практике, внедрение новой системы взамен существующей (тем более если разработчики, ее поддерживающие являются сотрудниками компании), всегда сопровождается сложностями. Договор в этом случае прикрывает нас, но не гарантирует отсутствие человеческого фактора
6.5
Чтож вас так на бюджете заклинило
Ну нету в этом гипотетическом примере откатов. Говорю как автор эссе... не подразумевалось там такого фатора.
Есть хороший анекдот про гребцов... Надо будет премировать менеджеров и уволить за неудачу админа для остарски...
А если без шуток, то количество систем внедренных на бумаге слиишком велико, чтобы об этом не говорить.
Какие следаны выводы автором:
И тут не все просто. Помимо формальных связей (начальник - подчиненный) есть (и еще как есть) неформальные (брат, сват, родственник, сестра, жена), которые могут вести далеко __наверх__. Придумать пряники и кнуты для такого специалиста, который является в равной степени некомпетентным и бессмертным очень сложно...
Тут я открыт для обсуждения особенно. Может у кого есть способы воздействия на подобных персонажей (варианты устранения родственников не рассматриваются).
И прошу отметить, что ЭТОТ человеческий фактор НЕ ВИДЕН до заключения контракта... Мало того, он даже проявится в проекте не сразу... Вот в моей истории были примеры компаний, где запрещалось на работу брать родственников... Но их было посчитать по пальцам одной руки (руки трехпалого ящера)
Может на стадии подписания договора экстрасенсов приглашать? Не знаю...
Какие сделаны выводы мной:
Опять бюджет
Хочу чтоб был учтен фактор неформальных связей. И фактор выполнения проекта на подряде.
В остальном вопросов нет. Такая точка зрения имеет место быть и бывает.
Уф...
Дальше отвечу телеграфно. Цитировать очень неудобно
"идти ли в проект, если видишь, что он закончится не очень успешно, но деньги заплятят" - это тема отдельного разговора и на этот вопрос статья не отвечает (расклад по вопросу не ясен).
Иногда бывают непопильные проекты.
Всегда неясно будет проект успешным или нет.
Никто заранее не знает что и как будет....
В том, что сказано далее все верно:
Делать сразу промышленное внедрение с закрытыми глазами в рамках предприятия (самоубийство чистой воды)
Для этого есть пилотные проекты (пилотный проект, подобно НИОКР, подразумевает как положительный, так и отрицательный исход)
И только после "пилота" все принимается опытно-промышленную и потом в промышленную эксплуатацию. Тут все верно.
(есть же масса методов внедрения: горизонтальные, вертикальные... итд)
В развитие темы и для подолжения данной темы дам ссылки (на дополнительную критику):
1. Презентация с конференции Training Labs 2008 http://cmcons.com/presentation/tl_cc_cq/
Там как раз есть тема про типы внедрения
2. Человеческий фактор в обучении при внедрении http://cmcons.com/articles/course/trainings_strategy/
3. Тоже эссе на тему как правильно внедрить http://cmcons.com/articles/analitika/cool_deploy/
Вроде все.
Спасибо за пост. Готов при доработке данной статьи взять в соавторы
26
Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...
« : 28 Июля 2009, 01:32:59 »Хм.. вообще вы знаете... а ведь это мысль!! Точно!Сроки мне не нравятся. Хояется хотябы лет 5
Большие человекоподобные роботы спасут отцов и матерей отечественного анализа!
осталось только ПО соответствующее написать (хы-хы, ну вот опять человеческий фактор...)
Если серьезно - это замечательно, что многострадальная ИТ хотя бы местами созрела для обсуждения человеческого фактора. Значит, лет через 10, может, таки доберутся до профориентации и подготовки специалистов к работе с людьми (а не только с методологиями).
Ну к тому времени, глядишь, и службы по персоналу будут работать в свом большинстве с персоналом, а не вакансиями
27
Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...
« : 28 Июля 2009, 01:30:49 »
Юр, при внедрении и одного прапорщика достаточно
28
Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...
« : 27 Июля 2009, 22:23:27 »
Можно сказать и немного по-другому
На каком уровне КУЛЬТУРА в конкретной организации...
Кстати, можно придумать шкалу влияния человеческого фактора в зависимости от уровнея CMMI
На каком уровне КУЛЬТУРА в конкретной организации...
Кстати, можно придумать шкалу влияния человеческого фактора в зависимости от уровнея CMMI
29
Консалтинг и Внедрение / Re: Человеческий фактор во внедрении процессов...
« : 27 Июля 2009, 21:49:41 »
Ну 100% - это наше всё. Хот, на самом деле, не совсем всё зависит от человеческого фактора. И зачем ждать профессиональных конференций
Предлагаю добить тему здесь (в смысле - набрать материала для конференции )
Предлагаю добить тему здесь (в смысле - набрать материала для конференции
)
30
Консалтинг и Внедрение / Человеческий фактор во внедрении процессов...
« : 27 Июля 2009, 19:42:00 »
Хочу открыть новую тему именно о человеческом факторе факторе во внедрении (не важно чего: процессов, автоматизированных систем и т.д).
Моя оценка по результатам внедрений наводит на размышления о 80%... то есть успех внедрения зависит на 80% от человеческого фактора и только на 20% от технологий и инструментов
Проиллюстрировать ЭТО хочу своей статьей (вернее зарисовками).
В основу статьи положены реальные примеры внедрений. Возможно, это не очень "форматная" статья, но тем не менее мне важны отзывы и комментарии. Так что прошу не стесняться
Читаем и комментируем http://anovichkov.msk.ru/?p=104
PS Возможно, по результатам обсуждения будет продолжение статьи...
Моя оценка по результатам внедрений наводит на размышления о 80%... то есть успех внедрения зависит на 80% от человеческого фактора и только на 20% от технологий и инструментов
Проиллюстрировать ЭТО хочу своей статьей (вернее зарисовками).
В основу статьи положены реальные примеры внедрений. Возможно, это не очень "форматная" статья, но тем не менее мне важны отзывы и комментарии. Так что прошу не стесняться
Читаем и комментируем http://anovichkov.msk.ru/?p=104
PS Возможно, по результатам обсуждения будет продолжение статьи...