Блог Александра Башкирова

ИТ и бизнес, компьютеры и ПО, фото, программирование и просто мысли…
Этот сайт в основном посвящен тому, что мне интересно вне работы. Ведется в порядке хобби.
Все изложенное на сайте - мое частное оценочное мнение и не может быть истолковано иначе.
Со всеми вытекающими из этого последствиями.

консалтинг

Про клиповость-2 (вдогонку)

Просмотров: 51Комментарии: 0
Alib.spb.ru

В прошлом посте (http://www.alib.spb.ru/blog/page/pro-klipovost-kak-trend) я писал про клиповость как тренд. И кажется недописал про главную опасность "клиповости". А именно о том, что знания, полученные "клипом" - автоматически возводят их получателя на внутренний пьедестал. Прошел страт-сесиию? Всё, теперь я стратег. Получил поверхностное представление о коучинге (одно-двухдневный курс "Коучинг для чайников") - всё, коуч вот он, готов. Прошел двухчасовой тренинг на тему управления - всё, готов великий управленец!

Увы. К сожалению, "клиповые" мероприятия не заменят ни опыта, ни дадут всех знаний... Они, в самом лучшем случае - расскажут как может быть. После чего - перед потребителем встанет совершенно свободный выбор: остаться с этим знанием или принять как факт, что он находится в начале большой дороги.

Возьмем, например, абстрактное мероприятие - однодневный вымышленный семинар по подготовке управленцев. Почему он может быть неэффективен? Да потому, что работа управленца - это каждый день, каждую секунду работать, фокусируясь, отвлекаясь, работая, выстраивая и поддерживая. Семинар может зарядить, может показать направление, дать импульс, дать модель - но он не сделает из слушателя человека, равного ведущему по опыту. То есть он не даст ни практики применимости, ни изменений человека. Слушатель, которому действительно надо - сможет найти способы взять максимум - путем поиска информации, допокупки консалтинга, поиска, проб и ошибок в конце концов. Это - позитивный путь. Негативный же - в том, что "проглотив" очередной клип информации, потребитель делает поспешные выводы - и радостный объявляет себя экспертом.

 

Про клиповость как тренд

Просмотров: 83Комментарии: 0
Alib.spb.ru

По мотивам статьи "Клиповый консалтинг: почему теперь это нормально" (https://www.e-xecutive.ru/management/practices/1987666-klipovyi-konsalting-pochemu-teper-eto-normalno)

Вот интересно - всем как бы самоочевидно что жизнь в текущем времени быстрее, чем была раньше. Я помню детство, которое пришлось на 80ые - не было такого "вселенского шухера", в смысле динамики жизни. Да, жили, были, не печалясь особо. Темп жизни, темп обучения - был сильно ниже, чем сейчас. Сейчас же имеем темп, который, кажется, постоянно растет. Это не хорошо и не плохо - это данность.

Следствием из этого темпа является то, что многие действительно серьезные вещи стали заменяться эразацем. А многие - трансформировались в quick-формат. Поясню.

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

Отсюда следует интересное заключение: фундаментальные прикладные (простите за "кривой" термин) знания в наше "быстрое" время способны дать неплохие дивиденты. При условии, что они будут продаваться в "коротком" формате.

Эту же тенденцию, кстати, я наблюдаю и среди наших заказчиков - мало кто хочет длинные проекты внедрения. Должно "взлететь" за неделю-две, максимум за месяц. И желательно - "без отрыва от производства". В некотором роде клиповость-enterprise.

А что вы думаете по поводу клип-форматов?

 

E-xecutive.ru: 6 причин провала реформ в компаниях

Просмотров: 582Комментарии: 0
Alib.spb.ru

Прочитал интересную статью на E-xecutive.ru:

http://www.e-xecutive.ru/management/practices/1986539-6-prichin-provala-reform-v-kompaniyah

Это о том, почему проваливаются реформы в компаниях. Я бы, правда, заменил "реформы" на "изменения". И все встает на свои места. Почему проваливаются изменения в компаниях? Причины из статьи:

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

Если изменения проводятся "абы как", по принципу "навались, прорвемся", то с большой вероятностью - такие изменения будут обречены на провал. Потому что несистемность - корневая причина всех перечисленных причин. И, чтобы вылечить их - надо заранее продумать изменения, подвести "базу" - то есть создать ценность изменений не только в головах ТОПов, но и в головах простых сотрудников (непростая, но решаемая задача), договориться о правилах работы, о правилах, ... как следует продумайте изменение и возможные сценарии, и "усё будет". В смысле, шансы получить управляемое изменение с желаемым результатом будут сильно выше, чем если этого не делать. Проверено на практике.

Роман Шерн. На чём и почему обычно экономят в первую очередь

Просмотров: 760Комментарии: 0
Работа

Вечер принес интересную статью про выбор управленческого консультанта. И вообще - любого консультанта, так или иначе связанного с процессами или внедрением.

Итак, статья - Роман Шерн. На чём и почему обычно экономят в первую очередь (ссылка).

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

Для затравки несколько вопросов:

  • как выбрать консультанта и не прогореть?
  • как получить максимальную отдачу от работы консультанта?
  • что на самом деле гарантирует консультант?
  • в чем причина того, что консультантам не доверяют?

Там нет каких-то однозначнвых рецептов, некоторые мысли мне кажутся "чересчур" или "недостаточно" - но в целом очень трезвая и полезная статья.

Павел Алферов: концепция контрольных точек

На Ютубе - отличное интервюью, которое дал Павел Алферов Павлу Софронову, по разработанной им методологии РИМ-3, и, в частности - по концепции контрольных точек. Что очень здорово - Павел прямо и открыто говорит об особенностях национального проектного управления. И о том, как эти особенности "вписать" в живой проект. Честно - восхищен, тем более, что знаю, "как это работает".

Ссылка на интервью:

https://www.youtube.com/watch?t=130&v=BB-TUZ_iHkw

Само интервью:

Пост про то, как надо писать ТЗ

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

И часто встречается ситуация, когда в роли ТЗ выступает все, что угодно... кроме, собственно, ТЗ. Почему так? Да потому, что ТЗ - это задание, на основании которого должна быть подготовлена система автоматизации. Не более - но и не менее. В роли ТЗ в общем случае не могут выступать прототипы экранов, список пожеланий и т.д. - потому что в итоге получится нечто, соответствующее ТЗ - но полностью или частично не соответствующее ожиданиям заказчика. Как избежать такой радостной ситуации?

Во-первых, всегда помнить - система, разрабатываетмая по ТЗ, автоматизирует процесс (напомню, речь идет о ТЗ на информационную систему - от интернет-магазина до ERP). Соответственно, в ТЗ обязан быть прописан процесс, который автоматизируется. Иного просто не дано: не понимая процесса, невозможно описать систему.

Второй аспект: ТЗ должно описывать результат "на выходе". И из этого следует еще один очень важный вывод: в ТЗ должны присутствовать варианты использования системы. То есть, должно быть описано, кто (какая роль) выполняет какой надор действий в системе. Да, и это должно коррелироваться с процессами, которые система автоматизирует.

Следующее, на что надо обратить внимание - это то, что будет автоматизироваться, а что - выполняться вручную. Отсюда должны роддиться требования к интеграции и функциональным модулям информационной системы (если применим).

Дальше имеет смысл расписать требования к формам и дизайну. Требования к формам, в идеале - это выделение критически важной информации длдя процесса, с анализом - когда, кто и в каком объеме поставляет нужную информацию. Требования к дизайну тут получаются вроде бы как не очень логичны... но логичны, потому что важно не только то, что будет нести форма в себе - но и то, как она будет выглядеть. Хотя требования к дизайну можно вообще поставить в конец ТЗ, или сделать ссылку на brandbook - тут вариантов масса.

Следующее, что нужно для разработки ИС - определить этапность. Что делаем и что запускаем в первую очередь, что - во вторую и т.д. Это очень важно - так как позволяет четко очертить пожелания Заказчика к тому, что должно работать в первую очередь, а что должно быть запущено в последнюю очередь. Кстати, если есть сроки - то им место тут же.

Дальше, собсвтенно, если есть понимание на какой базе строим ИС - нужно расписать это. Если ИС создается "с нуля" (бывает и такое) - то указать, на каком яыке она пишется, какие библиотеки требует и т.д.

Дальше, моделируем ситуацию, когда готов прототип. В ТЗ на этот случай надо указать, кто и как тестирует, желательно - порядок работы с замечаниями (по хорошему, это в устав проекта идет, но на край можно и в ТЗ).

Дальше, нужно описать, что надо будет сделать, чтобы ввести систему в эксплуатацию.

Дальше приводятся так называемые "потребительские характеристики системы" (время отклика, число кликов по основным операциям и т.д.). И приводится то, что влияет на эти характеристики - например, конфигурацию серверного оборудования, операционные системы, лицензии и т.д.

Дальше, прописываются требования к тому, что будет включено в понятие "результат". То есть, что и в каком виде будет передано Заказчику - документация, исходные коды, скомпилированные модули и т.д. Исходя из этого, следующий логичный пункт - состав и структура документов, которые будут переданы Заказчику по окончанию процесса разработки / внедрения. Тут имеется в виду как "пользовательские" документи, такие, как ролевые инструкции, инструкции по профилактике, обслуживанию, устранению типовых ошибок и т.д., так и общетехнические документы - описание архитектуры решения, проектная документация.

Финальным аккордом нужно описать процедуру приемки-передачи системы (в целом и по каждоому этапу). А также привести требования к информационной безопасности.

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

В общем, получился почти на тему "как написать ТЗ" :) И, прошу отметить - никакого ГОСТа. Хотя структура получилась в чем-то похожей на то, что трбует ГОСТ 34 от ТЗ. Но, наверное, его проектировали, исходя из аналогичных (или в чем-то похожих) соображений.