Вы упомянули 2 школы кризисного менеджмента. Можно узнать какой школы и каких методологий менеджмента придерживается лично Вы?
Я придерживаюсь обоих подходов.
Имея опыт кризисного проектного управления могу сказать что в условиях острой ситуации нужно действовать решительно и быстро. В то время как в «мирное» время, подход должен быть иным, но также иметь цель. Только в отличии процесса спасения системы (в моем случае проекта) цель рутинного менеджмента — эффективное достижение результата. Именно этого принципа я придерживаюсь в своей работе — получение наилучшего результата наименьшими усилиями в соответствии с требованиями качества, принятыми в компании. И здесь мне помогают лидерство и бережливое производство.
В статье, как мне показалось, прослеживается основной мотив «сохранения процессов», и только вскользь «сохранения людского ресурса» в контексте основного средства производства IT-компаний. Есть ещё множество факторов, да и в целом стратегии управления сконцентрированные вокруг продуктов компании, монетизации этих продуктов. Вы полагаете, что управление процессами первично (поменяем их, останутся и люди, и продукты будут деньги приносить)? Можно узнать в какой сфере более применим такой подход (есть гипотеза, что не во всех)?
Скорее на оборот, я старался показать необходимость изменений, которая в первую очередь касается процессов. Согласно стандарту ISO 9000:2000, процесс определяется как деятельность по преобразованию входов в выходы под воздействием ресурсов. Для IT-компании ресурсы — это люди, соответственно, меняя процессы, влияние оказывается и на ресурсы — сотрудников, т.е. оптимизируя одно, требуется затронуть и другое.
Тезис о концентрации управления вокруг продуктов мне, честно говоря, не понятен. Считаю, что компания живет только тогда, когда зарабатывает деньги, а деньги ей приносят клиенты — пользователи продуктов в вашем случае. Тогда логичнее говорить об удовлетворенности клиентов, с одной стороны и увеличении маржинальности, с другой. Удовлетворенность клиента растет от предоставления ему качественного и востребованного продукта, а маржинальность от снижения затрат на производство. Будь это тяжелая промышленность, уместно было бы говорить об экономии сырья путем снижении брака конечной продукции, но раз у IT-компании нет иного сырья кроме «интеллектуального», то быть эффективной она может только за счет оптимизации внутренних процессов.
Имею основания предположить, что такой подход имеет место во всех сферах — от сферы услуг и машиностроения до высокотехнологичных производств и ИТ-бизнеса, если, конечно, не брать в расчет компании, имеющие государственную поддержку, компенсирующую все убытки производства.
В текущей версии решения для передачи карточек пациентов используется fhir-ресурс Patient. Некоторое время назад использовали Provenance для учета источников данных (карточек), но сейчас решили отказаться от него.
В разделе «Природа требований к программному продукту» сказано, цитирую: Если в процессе размышлений о способе решения проблемы ЛПР придет к выводу, что достижению поставленной цели будет способствовать автоматизация деятельности организации, то одной из разрабатываемых им операций станет внедрение соответствующей информационной (автоматизированной) системы.
Как именно найти настоящую проблему?
Анализ способов выявления проблемы и формирование образа решения не являлся целью настоящей статьи.
Да, в нашей культуре слово «проблема» носит исключительно негативную окраску, равно как и слово «конфликт», например. Но это очень узкое понимание термина.
Потому что иначе в качестве проблемы берётся, например «У нас нет CRM»
В статье сказано, что наличие или отсутствие автомитизированной системы не может являться проблемой — это предположение заинтересованного лица о том, что операция по ее внедрению изменит сложившуюся на предприятии ситуацию. Какую ситуацию? Выяснить это и является задачей проектной команды (в частности, аналитика) и потом внедрить не просто CRM, а CRM с требуемой функциональностью.
«Считается» — очень подходящее слово. На деле же оказывается иначе — пользователи и менеджеры формулируют свои пожелания к поведению программы, а команда проекта сначала выясняет чем поможет пользователям требуемое поведение, а уже потом предлагает соответствующее программное.
Концепция по ГОСТУ и Vision — это не совсем одно и то же. Точнее, совсем не одно и то же.
Greesha, я не ставил в один ряд ГОСТ и Vision, а лишь сказал, что оба указанных подхода отталкиваются от Проблемы.
Подстроить бизнес-процесс под инструмент можно сравнительно легко только там, где этот инструмент даёт явные преимущества всем его участникам. Например, если вы внедряете АБС в банке, в котором до сих работают только с экселем, то вас наверняка встретят с распростёртыми объятиями (правда, таких банков уже не осталось). А вот при попытке поменять одну АБС на другую вы наткнётесь на жёсткое сопротивление пользователей на всех уровнях: процессы уже устоялись, и поменять их можно только боем, с кровью и потерями.
Не соглашусь с Вами. В грустной истории проблема заключалась как раз в том, что внедряемый инструмент ломал сложившийся бизнес-процесс, не предлагая ничего взамен, а даже наоборот, порождал у врачей жуткий когнитивный диссонанс своей функциональностью.
Был в моей практике пример, когда в организации заменялась информационная система. Так пользователи просто отказывались работать в старой системе, видя как их коллеги работают в новой.
А все почему? Потому что, в первом случае, функциональность программного продукта никак не соотносилась с потребностями пользователей, в то время как во втором, реализованная функциональность прямо коррелировала с выявленными потребностями и удовлетворяла их.
Что за мещанская склонность к искажению смысла цитируемого текста и желание интерпретировать его в удобном для себя контектсте? А контекст тут простой — самопиар, ведь цитирующий руководит и преподает в указанной Школе.
Моя фраза полность звучит так:
Я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы, по указанным стандартам, готовились постфактум и носили формальный характер.
Кроме того, в ГОСТ'е нет понятия «информационная система», а есть термин «автоматизированная система» (см. ГОСТ 34.003-90). Именно это, а не выдернутая из контекста фраза, иллюстрирует кто с чем не знаком. :)
Конечно будут, только их представление может быть разным. Например, в вашем случае это может быть стикер на доске, задача в трекере, документ на одну страницу — все, по чему разработчик сможет понять задачу, а тестировщик разработать сценарий тестирования.
Не согласен с тем, что Вы заведомо усложняете. Разве где-то сказано, что для проверки гипотезы нужно потратить большое количество времени на разработку спецификации по стандарту IEEE 830, например? Скорее наоборот.
разделение на «уровни взросления» между строк говорит, что 1 — это детский лепет, а 5 — это круто и солидно
В свое повествование я вкладывал несколько иной смысл:
принятие решения о достижении того или иного уровня зрелости процесса управления требованиями должно осуществляться взвешено и на основании четкого понимания целей и задач, стоящих перед командой проекта или компанией
и еще
достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом
Я сам сторонник того, что бОльший уровень развития порождает бОльшие накладные расходы. Это не всегда бывает оправдано и только крупная компания может себе позволить пожертвовать производительностью в угоду управляемости.
Что же касается категоричности, то я смягчил формулировку в статье.
ncix, не соглашусь! Не важно, какой заказчик — внешний или внутренний, важно, что у каждого программного продукта есть заинтересованное лицо или лица, которые ждут от него разрешения своих проблем (удовлетворения потребностей). И команда проекта должна быть нацелена как раз на удовлетворение этих самых потребностей, а не на реализацию собственного видения решения, изучение новых технологий и т.д. То есть основная задача состоит в синхронизации видения конечного продукта между всеми участниками проекта. В каком виде описывать и насколько подробно доносить — это вопрос другой, но требования должны быть!
Leonid76, я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы по указанным стандартам готовились постфактум и носили формальный характер. Если же требования и готовились перед началам проекта, то исключительно для того, чтобы потешить самолюбие заказчика, повторяющего магическое заклинание: «Техническое задание». После чего про документ забывали и начинали просто «кодить».
По поводу косноязычия согласен, но уверен, что не один я сталкивался с «трудностями перевода» при чтении документа, написанного литературным языком, но сплошным текстом.
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов. Указанные активности являются показателями зрелости процесса и если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Я придерживаюсь обоих подходов.
Имея опыт кризисного проектного управления могу сказать что в условиях острой ситуации нужно действовать решительно и быстро. В то время как в «мирное» время, подход должен быть иным, но также иметь цель. Только в отличии процесса спасения системы (в моем случае проекта) цель рутинного менеджмента — эффективное достижение результата. Именно этого принципа я придерживаюсь в своей работе — получение наилучшего результата наименьшими усилиями в соответствии с требованиями качества, принятыми в компании. И здесь мне помогают лидерство и бережливое производство.
Скорее на оборот, я старался показать необходимость изменений, которая в первую очередь касается процессов. Согласно стандарту ISO 9000:2000, процесс определяется как деятельность по преобразованию входов в выходы под воздействием ресурсов. Для IT-компании ресурсы — это люди, соответственно, меняя процессы, влияние оказывается и на ресурсы — сотрудников, т.е. оптимизируя одно, требуется затронуть и другое.
Тезис о концентрации управления вокруг продуктов мне, честно говоря, не понятен. Считаю, что компания живет только тогда, когда зарабатывает деньги, а деньги ей приносят клиенты — пользователи продуктов в вашем случае. Тогда логичнее говорить об удовлетворенности клиентов, с одной стороны и увеличении маржинальности, с другой. Удовлетворенность клиента растет от предоставления ему качественного и востребованного продукта, а маржинальность от снижения затрат на производство. Будь это тяжелая промышленность, уместно было бы говорить об экономии сырья путем снижении брака конечной продукции, но раз у IT-компании нет иного сырья кроме «интеллектуального», то быть эффективной она может только за счет оптимизации внутренних процессов.
Имею основания предположить, что такой подход имеет место во всех сферах — от сферы услуг и машиностроения до высокотехнологичных производств и ИТ-бизнеса, если, конечно, не брать в расчет компании, имеющие государственную поддержку, компенсирующую все убытки производства.
В разделе «Природа требований к программному продукту» сказано, цитирую:
Если в процессе размышлений о способе решения проблемы ЛПР придет к выводу, что достижению поставленной цели будет способствовать автоматизация деятельности организации, то одной из разрабатываемых им операций станет внедрение соответствующей информационной (автоматизированной) системы.
Анализ способов выявления проблемы и формирование образа решения не являлся целью настоящей статьи.
В статье сказано, что наличие или отсутствие автомитизированной системы не может являться проблемой — это предположение заинтересованного лица о том, что операция по ее внедрению изменит сложившуюся на предприятии ситуацию. Какую ситуацию? Выяснить это и является задачей проектной команды (в частности, аналитика) и потом внедрить не просто CRM, а CRM с требуемой функциональностью.
Greesha, я не ставил в один ряд ГОСТ и Vision, а лишь сказал, что оба указанных подхода отталкиваются от Проблемы.
Не соглашусь с Вами. В грустной истории проблема заключалась как раз в том, что внедряемый инструмент ломал сложившийся бизнес-процесс, не предлагая ничего взамен, а даже наоборот, порождал у врачей жуткий когнитивный диссонанс своей функциональностью.
Был в моей практике пример, когда в организации заменялась информационная система. Так пользователи просто отказывались работать в старой системе, видя как их коллеги работают в новой.
А все почему? Потому что, в первом случае, функциональность программного продукта никак не соотносилась с потребностями пользователей, в то время как во втором, реализованная функциональность прямо коррелировала с выявленными потребностями и удовлетворяла их.
Думаю, дальнейшая дискуссия выходит за рамки обсуждения темы обсуждаемой статьи. Предлагаю на этом остановиться.
Моя фраза полность звучит так:
Кроме того, в ГОСТ'е нет понятия «информационная система», а есть термин «автоматизированная система» (см. ГОСТ 34.003-90). Именно это, а не выдернутая из контекста фраза, иллюстрирует кто с чем не знаком. :)
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/ManagementMaturity_TheRationalEdge_Feb2003.pdf
В свое повествование я вкладывал несколько иной смысл:
и еще
Я сам сторонник того, что бОльший уровень развития порождает бОльшие накладные расходы. Это не всегда бывает оправдано и только крупная компания может себе позволить пожертвовать производительностью в угоду управляемости.
Что же касается категоричности, то я смягчил формулировку в статье.
Leonid76, спасибо за обратную связь!
По поводу косноязычия согласен, но уверен, что не один я сталкивался с «трудностями перевода» при чтении документа, написанного литературным языком, но сплошным текстом.
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов. Указанные активности являются показателями зрелости процесса и если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме.