Как стать автором
Обновить

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

Проблема давно уже не в технарях. Бизнес-процессы те же алгоритмы, это понятно любому.
Проблема в том, что у руля стоят люди с улицы — свояки, знакомые, родственники. Которые просто не готовы к руководящим постам.
Происхождение руководства заказчика тема отдельная. Но тут уж или смирись или умри. Они платят деньги, а мы за эти деньги должны выполнить работу. Будь они хоть буратинами деревянными, в конце проекта они должны принять работу и выплатить остатки денег. А успех сдачи работ зависит от того, что мы заложим в проект и в архитектуру системы. В моих примерах виноваты, все же, исполнители. В первом случае они прозевали бизнес заказчика, а во втором переоценили самого заказчика.
У исполнителей тут дело скорее в том, что у них зачастую нет человека достаточно разбирающегося в предметной области, а консультанта нанимать жаба душит.
Чем то напоминает мое начальство, которое любит говорить: «Вот тебе задача и срок в 8 часов, ты посмотри там, как немцы в SAPе предложили и расскажи нам, может подойдет». И потому мы уже который год до сих пор «с нарисованными нашивками маршируем по плацу и шаманим перед муляжом радиостанции».
Классика :) В БД САПа около 70 тысяч основных таблиц, безумное количество транзакций, свои методики ведения проектов, построения архитектур… Нет, 8 часов мало, надо было давать все 16.
Вам 2,43 секунды на таблицу кажется мало? Вы прямо как непрофессионал.

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

Ну и чтобы два раза не вставать.
Культ карго у нас глубже, то есть выше, чем уровень принятия решений об автоматизации. Одни айфоныш с нанистом чего стоят. Но корни проблемы да — тотальный культ карго пока рулит, ему служить выгодно и популярно.
И таки будет! Главное, чтобы заказчик это понял. Мне в этой связи вспоминается реплика персонажа из мультика «Тачки»: Ты не знешь, чего тебе нужно, Луиджи знает чего тебе нужно!
И, причем, "еще вчера"!
Сказано хорошо, но между своими. По-хорошему, это надо чуть переделать и давать всем заказчикам ДО подписания контракта. Тогда будет толк.
Контракты часто подписываются в бане, и не всегда возможно вклиниться в этот процесс. Лоббисту, конечно, дают материалы и наброски предложений. Но вот бывает, что после пятого стакана вискаря он забывает слова и путается в концепциях.
Типичные примеры того, что снятие задачи — ключевой этап в процессу автоматизации СУ. Опыт показывает, что изначально ни один заказчик — ни один! — не представляет себе задачу со всех необходимых сторон. И это нормально, а не признак тупости или некомпетентности.
Разработчик же в свою очередь обязан понимать риски и закладывать их в проект. Многих аналитиков/пээмов приходится принудительно приучать, что максимально ясное понимание и описание задачи нужно в первую очередь нам, а не заказчику, что чем больше бумаги, тем чище жопа, и в то же время одна лишь бумага не спасет сложный проект, если нет прямого налаженного контакта с ЛПРами. Это трюизмы, конечно, но реально многие люди при выходе в поля забывают об этих базовых вещах.
Да, опыт тут ценнее всего… Приведенные примеры, кстати, касались первых внедрений новых для нашей страны систем. Внутри опыта не было ни у кого, отсюда и такие фактурные грабли.
Когда внедряется что-то более привычное, нужно опираться на опыт свой или коллег. Обязательно.
Думаю, что и не только новые системы (достаточно курпные) до сих пор внедряются аналогично. Исключения, как мне кажется, очень редки. Даже зачастую проекты, кажущиеся снаружи успешными, на самом деле успешны очень недолго, один-два года… пока не ушли энтузиасты их постоянно «поддерживающие». Именно «поддерживающие», а не сопровождающие.
Да, вы правы. Вопрос жизнеспособности систем достаточно тонкий и требующий дополнительного изучения. У меня есть мысль написать об этом, но пока никак не нащупаю идею.
Скажите, что нужно сделать, чтобы научиться распознавать такие ситуации?
Эти все проекты прошли через вас?
Основные общие признаки даны в выводах. Детально можно писать только о конкретных проектах, а не вообще.
Если повторяться, то нужно подумать, чего же именно хочет заказчик. Буквально сегодня читал очень хороший материал на эту тему habrahabr.ru/blogs/pm/128786/

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

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

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

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

А «структурированных трудов» на тему много написано, хоть обчитайся. Беда только в том, что западные книжки написаны в расчете на людей, имеющих небольшое представление о классическом менеджменте. А у нас в эту область влезают в основном программисты, которые ничего не видят, кроме алгоритмов и программ…
А что вы понимаете под «классическим менеджментом»? Это я для того, чтобы сравнить понятия у вас и у меня, ввязавшись в дискуссию. :)
Потому как я вижу немного обратную ситуацию, пройдя некоторую ступень эволюции (так же быв программистом), увидел что действительно, большинство бизнес-аналитиков, внедренцев и пр людей причастных к построению бизнес-процессов в компаниях бывшие ИТишники. Будь то они программистами, сисадминами или еще кем-то. И они перкрасно понимают где алгоритмы, а где менеджмент.
Сфера, в которой мне больше приходится сталкиваться — различные сферы услуг, без пр-ва какого-то товара. А у вас, судя по тексту как раз наоборот — пр-во в полный рост. Возможно в этом проблема? ИТишники не хотят идти в пр-во, т.к. «с рождения» не производили товары?
У меня нет законченного второго образования в области управления, но мне приходилось и учиться на специальных курсах и управлять людьми, а также лично ставить процессы. Я много лет работал на
Классический менеджмент — это как минимум что-то в рамках элементарного учебника:
— как ставить задачи и контролировать исполнение
— основы мотивации
— проблемы во взаимодействии

Без знания подобных вещей трудно спроектировать бизнес-процесс. Это ведь не квадратики в программе рисовать, как может показаться. Это в первую голову организация взаимодействия людей. Программы тут только на втором плане.
Полезная статья и написана очень хорошо — интересно читать, хоть и много текста. Автор, пишите еще.
Рад стараться!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.