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