?

Log in

No account? Create an account

On the way to global optima.

Практики


Previous Entry Share Next Entry
В чем ценность программного решения?
belique
Продавцы программных продуктов вплоть до Microsoft делают упор на учетной способности своих продуктов. Они же любят называть программы решениями. «Программное решение проблем клиента»
Если я веду дела в блокноте, привести статистические данные по работе не представляется никакой возможности. Другое дело с электронным помощником, который с точностью до секунды расскажет о том, сколько, где и когда. Это преимуществом становится только тогда, когда эти данные используются другим процессом, а не пылятся в архиве. И если регулярно не проводятся обзоры работы и никто целенаправленно не улучшает делопроизводство, то аналитическая способность программ не такое уж и весомое преимущество для потенциального покупателя. Еще одна беда аналитики в том, когда данные нельзя связать с конкретными действиями или связывают черт те что. Аналитика бесполезна или даже вредна для тех, кто ей никогда не пользовался. Учитывая пассивную роль покупателя на этом рынке, странно что производители программных продуктов продолжают гнуть свою линию.
Продают положительные отзывы тех, кто пользуется купленным решением. Потенциальная выгода определяет масштаб преобразований в текущей работе. Вот Micosoft написал статью с 6 не самыми очевидными причинами почему провалились проекты. Интересно проследить логику исследования:
Причина 1
Статичные методы — по итогам проекта стало ясно, что если бы использовали гибкие методологии, то избежали бы провала?
Причина 2
Недорогие программные решения — используй они дорогие, звезды бы сошлись иначе? Они правда в это верят?
Причина 3
Неэффективное управление виртуальной командой — звучит умно, а информации ноль. Более того, это констатация факта, который похож на следствие, а не причину.
Причина 4
Слабая поддержка руководителя —  была бы сильная, проекты бы взлетели — откуда они это узнали? Все проекты с сильной поддержкой руководства добивались успеха? Really?
Причина 5
Несоответствие целям и стратегиям предприятия — немудрено для компании с несколькими стратегиями. Наконец таки упомянуты конфликты и потери, к которым они приводят.
Причина 6
Сбой в коммуникациях — «К счастью, последние исследования говорят о том, что покупка правильного программного обеспечения для управления проектами может значительно улучшить коммуникацию внутри команд, а также коммуникации с клиентами. Возможность связываться в реальном времени с членами своей команды, расположенных ниже этажом или в другой стране с помощью инструментов, созданных для передачи критически важных сообщений быстро и безопасно – это ключевой фактор для успеха проекта.»
Один или даже несколько сбоев в коммуникациях по мнению Microsoft могут быть причиной провала проекта. Интересно, они искали, что являлось причинами этих сбоев?

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


А ведь мир становится сложнее с каждым днем.
Tags:


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

Больную тему затронул )

Димон, я как раз про это и спрашиваю, если производители так сильно зависит от way of using, почему бы не озаботиться «проблемой интегратора», которого по твоим словам не пускают внутрь процессов. Продажники могут наобещать чего угодно, но ведь это ж свои кадры, почему язык работает в отрыве от мозгов?

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

Плюс сферы это еще новые, мало кто их до конца понимает.

Какие новые сферы ты имеешь в виду?

Управление людьми, рисками, финансами и т.д.

Смотри, вот ты технарь. Твоя задачи держать и развивать систему. Ты знаешь о неё дохрена и больше. Знаешь её сильные и слабые стороны. Посвещаешь ей 8 часов в сутки.

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

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

Чем мне нравится метафора системности — так это новыми задачами, которые появляются при ее развитии и как компания решает, что с этим делать.
Дим, если ты из технарей растешь до РП, разве задача держать и развивать систему остается на тебе? Не появляется человек на твое место, а ты теперь выполняешь старые и новые задачи одновременно?

Конечно остается на РП!
Понятно что какие-то технические моменты отваливаются от РП, но РП должен лучше своего технаря должен понимать возможности и ограничения системы. Может РП не будет знать как в тонкостях всё настраивается, но иметь представление о системе на уровне ОЧЕНЬ хорошего пользователя обязан.

Хм, а когда ты был технарем, твой РП разбирался в системе лучше тебя?

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

Как тогда вообще случилось, что технарь стал РП?

Воу воу воу.
С чего ты решил что стал? Вообще же о другом говорили.

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

В чем сила брат?

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

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

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

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

2.Недорогие программные решения - не хотели на этапе договора платить за консалтинг заплатили только за часы программистов.

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

ну и далее тоже можно расшифровать... надо просто синтезировать все пункты.

  • 1