MaksWiki - Новые страницы [ru]

Разделение рисков и успеха бизнеса для разных уровней Спиральной динамики

2018-07-25T23:13:42Z

MaksTsepkov:

Обсуждение бирюзовых организаций и уровней Спиральной динамики применительно к организации бизнеса требует понимания, как именно на разных уровнях переосмысливаются основные понятия, требуемые в бизнесе, и в результате происходит изменение культуры организации. В своих докладах и статьях я рассказываю, как изменяется понятие ответственности, включения в коллектив, взаимоотношений с заказчиком и завершения проекта, посмотреть это можно в статье Краткое описание уровней Спиральной динамики. А в этой статье я остановлюсь на том, как на разных уровнях представляется еще два важных аспекта бизнеса — разделение рисков бизнеса и разделение успеха, связанное с получаемым вознаграждением.

Фиолетовые компании — маленький бизнес своих людей в непонятном и потенциально враждебном окружении. Успех — на всех, но не равно, а по старшинству и авторитету — старейшины выделяют надлежащую долю, а риски — ну, что ж, это всегда можно случиться надо вместе защищаться и спасаться. И такое восприятие может быть у сотрудников как правильный порядок даже при работе в больших компаниях, бывают попытки построить маленький автономный отдел с такими правилами, и сетования на то, что как-то это плохо получается.

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

Синие компании устроены правильно, действуют по регламентам, в которых каждому определена справедливая доля вознаграждения в случае успеха. А сам успех — гарантирован хорошим планированием, в котором учтены все риски, и потому результат обязательно будет достигнут. Синий уровень — коллективный, и сотрудники таких компаний с подозрением относятся и к сильным лидерам, которые претендуют на участие в успехе, потому что именно они были во главе, и к предпринимателям, которые увидели и реализовали какие-то возможности и тоже хотят свою долю успеха. Они полагают, что и те и другие — просто выполняли свои служебные обязанности, так за что им какое-то особое большое вознаграждение? И это — источник конфликтов, если компания имеет смешанную структуру. И бесчисленных холиваров в соцсетях: надо ли хвалить сотрудников за хорошую работу, ведь он и так получает за это зарплату — типичный пример.

Оранжевый уровень — удачное предпринимательство, успех которого основан на знании истинного устройства мира, умение найти в нем точки приложения сил и получить большой эффект от небольшого воздействия. На этом уровне все люди делятся на две категории: предприниматели — те, кто понимают устройство мира и способны эти точки воздействия найти, и все остальные, кто способен только исполнять знакомые задачи. Все остальные, исполнительная машина — из синего уровня, предприниматели нанимают их, те работают за зарплату, и делают свое дело, но не несут никаких рисков. И, естественно, не должны претендовать на разделение успеха. Успех делится предпринимателями, и не поровну, а как договорились, или как кто кого перехитрил. И риски — так же. Потому что предприниматель ведь никогда не выкладывает полную картину мира, он показывает то, что нужно для деятельности. Это не значит, что он действует вообще без правил — но он понимает правила общества, в котором действует, как часть устройства мира, включая не только правила, но и дырки в них. И считает вправе самостоятельно решать, какие правила он будет соблюдать, а где пойдет на риск нарушения.

И вот здесь следует остановиться и подробнее рассмотреть конфликт, который часто возникает в инновационных бизнесах между ученым, изобретателем или программистом, который придумал и разрабатывает идею продукта, и предпринимателем, который этот продукт продвигает и продает, а часто и организует производство как менеджер. Очень часто это конфликт между синим и оранжевым уровнями, и стороны принципиально не понимают друг друга. Ученый полагает, что предприниматель просто выполняет свою работу — продает, заключает контракты, организует работу. И в этом нет ничего сложного, обычная профессиональная деятельность. Он бы и сам смог, если бы выучился, но у него — другая профессия. Главное — предприниматель-менеджер не делает же ничего принципиально нового, все описано в учебниках, надо их исполнять, какие такие риски и идеи? Вот он сам — другое дело, он придумал принципиально новую идею, аналогов — нет или они сильно уступают, и делает на ее основе замечательный продукт, который, естественно, завоюет мир — как и положено всем замечательным продуктам. В свою очередь, предприниматель тут знает, что придумать идею — не главное, главное — ее продать, и организовать уверенное производство. Что по процедурам это успешно не делается, это очень во многом вопрос личных умений, способностей рассчитать риски и вести переговоры. И видит полную неспособность ученого это все сделать, видит, что тот не соблюдает сроки и нарушает обещания, что новый инновационный продукт оказывается вовсе не столь работоспособным, как обещано и не готов к сроку. И потому, когда речь идет о разделении успеха, то каждый из участников претендует на главную долю, потому что он оценивает свой вклад как главный, а за партнером знает длинный список нарушенных ожиданий. И то же срабатывает при неудачах, каждый полагает, что в неудаче большая часть вины — на другом, и каждый прав, если смотреть с его уровня ценностей. А стартап, новое дело — это ведь смесь успехов и локальных неудач и трудностей завершения очередного этапа. На которых разваливаются многие успешные тандемы, потому что каждый еще и склонен переоценивать свою способность довести дело до результата без другого.

Этот конфликт я наблюдал несколько раз в реальной жизни, и он — тяжелый. Кстати, в свое время про компанию CUSTIS, где я до сих пор работаю, один человек с удивлением отозвался: «Очень интересная компания. У вас столько физтехов, и вы до сих пор вместе. Обычно при успехе такие компании разваливаются на выяснении, кто из участников круче». Для решения очень важно признать за другим его вклад, и понять его логику решений, мыслить на его уровень. А это, если рассматривать с точки зрения Спиральной динамики, требует от участников подняться даже не на зеленый, а на желтый уровень. Не обязательно осознано — достаточно в своей интуитивной картине мира. Но подняться. О желтом уровне я поговорю позже, а пока — про зеленый.

Зеленый уровень отрицает риски. Он постулирует, что если хорошие люди вместе возьмутся за дело, то у них — обязательно получится. Плохих людей — просто не надо звать, но вообще плохие — редкость, гораздо чаще встречаются просто не понимающие, им надо объяснить — и они присоединятся. Успех — можно делить поровну, можно — по потребностям, и это не слишком важно, потому что успеха обязательно будет много, так устроен мир, еще раз: если хорошие люди вместе возьмутся за дело, то у них — обязательно получится. Рано или поздно, так или иначе. И с последней оговоркой это не выглядит так уж утопично, особенно в современном мире. И основной вопрос в том, как быть, если на пути к успеху все-таки встречается слишком много трудностей, и он оказывается дальше, чем ожидался. Если при этом у людей продолжает звучать зеленая струна, говорящая о том, что это — бывает, и что всяк может устать или не рассчитать силы и остановиться, но тогда уж и доли общего успеха потом не получить — то ок. Но часть начинают звучать струны предыдущих уровней, Спиральная динамика говорит о том, что они просыпаются в период трудностей. И в этом случае возникает диссонанс. Потому что они требуют выделения справедливой доли за пройденную часть пути на синем, а на оранжевом — еще и признания вклада в виде идей и действий, которые позволили дойти до текущего момента. И вот если конечного, ожидаемого феерического успеха еще нет, но текущий, более скромный — есть, то люди эту долю хотят получить здесь и сейчас, не вкладывая далее эти средства в движение по пути. И в этом месте может быть серьезный конфликт.

Желтый уровень. Он признает, что люди — разные, у каждого свои способности и свои потребности в вознаграждении. И на нем команда людей, дополняющих друг друга и объединенных общей целью идет к успеху. Принимая и разделяя риски, и заранее понимая, зачем этот успех нужен каждому из членов команды. И как его делить, но не в том смысле, что резать на кусочки, как на предыдущих уровнях, а в смысле разделять и переживать совместно. И то же относится к рискам. И на этом пути еще и уважается свобода воли и изменчивость самих людей. Признается право не только устать, но и измениться и решить пойти другим путем. Однако, при этом надо выполнить текущие обещания и изменить контракт. Поэтому все контракты и обещания — срочные, и для них есть процедуры, позволяющие их изменить или расторгнуть, которые тоже были известны заранее, и которые были приняты. Собственно, такая форма называется на юридическом языке неоклассическим реляционным (отношенческим) контрактом. Она предназначена для контрактов в условиях неопределенности, когда признается, что мы не можем оговорить в контракте все условия заранее, зато можем заложить в контракты процедуры, позволяющие с этим неопределенностями работать. А желтый уровень признает, что область действия таких контрактов — вся жизнь, потому что она полна неожиданностей и сюрпризов, а сами люди — меняются и преподносят сюрпризы друг другу, и это — рабочая ситуация. И в этом мире можно и нужно пускаться в совместные предприятия для достижения цели, и достигать их.

Это — достаточно сильная смена восприятия и рисков и успеха. В этом ничего удивительного, потому что на этом уровне меняется и бизнес в целом: ведь прибыль и экономика превращается из целевой функции в ограничение деятельности. А это означает, что граница между коммерческими и некоммерческими организациями, между бизнесом, хобби и другой деятельностью размывается или вообще исчезает. Для меня эта концепция достаточно очевидна, поэтому я не знаю, насколько ее получилось понятно описать. И тут я готов отвечать на вопросы. И я подчеркну, что для меня это — не утопичная концепция неопределенного будущего, что она достаточно активно реализуется в мире, и чем дальше — тем больше таких компаний и организаций. За ней не просто будущее, за ней — ближайшее и обозримое будущее, и уже сейчас почти любой может при желании найти себе такую компанию. В IT — точно, но не только в IT.

И, наконец, бирюзовый уровень. О нем писать сложно. Про устройство организаций желтого уровня есть исследование Фредерика Лалу, книга которого «Открывая организации будущего» (мой конспект) — именно про желтый уровень Спиральной динамики, которому в оригинале соответствовал цвет teal, а не turquoise, коллизию сделал переводчик. А бирюзовый уровень никто не исследовал, хотя прототипы, на мой взгляд, уже формируются — можно смотреть на некоторые крупные open source проекты в IT, поддерживаемые сообществами, на такие массовые движения, как живые города, на сообщество соавторов википедии, и на многое другое. Если обобщать, то внутри действует множество инициатив, каждая из которых оформляется желтой командой, самостоятельно работает со своими рисками и успехом, но при этом, ощущая себя частью более широкого сообщества, делится успехом и с другими участниками, и помогает им в случае рисков и сложностей. Пока это сильно неформально, потому что существующие механизмы фиксации договоренностей не могут эффективно поддерживаться при высокой динамике изменений, особенно в случае сильно отложенного успеха, и вклада большого числа участников, и потому жизнь идет неформальна. Но тут нам должны помочь технологии блокчейн и смарт-контрактов, которые, думаю, сильно повлияют на устройство мира в этой части.

И в заключении — схема, краткая сводка написанного по уровням.

Основания Спиральной динамики

2018-07-25T23:07:04Z

MaksTsepkov:

Въедливый Олег Клименко решил разобраться с научными основаниями Спиральной динамики, за что я ему очень благодарен: в обсуждениях к посту Олега в группе Спиральная динамика получилось сформулировать довольно много содержания, которое я здесь изложу в виде целостного текста. А еще обсуждение привело к совершенно неожиданному открытию: когда осенью 2013 я заинтересовался Спиральной динамикой, мне офигенно повезло. Я наткнулся на описание истории экспериментов Грейвза, которые легли в основу теории, и она вызвала уважение. Оказывается, этой истории нет в книге Дона Бека и Криса Кована. Более того, большая загадка, откуда автор текста взял эти материалы: он ссылается на сайт http://spiraldynamics.com, но ни сейчас, ни в старых версиях сайта, который помнит archive.org истории экспериментов мы не нашли, нет их и на сайте самого http://ClarewGraves.com. Так или иначе, ссылка на историю сохранилась в моем первом посте: История возникновения уровней Грейвза на сайте NLPinp. Там указан автор Ilya Goz и дана ссылка на оригинал, который лежит в большой коллекции fido по вопросам психологии (оглавление) (06.08.2024: обе ссылки ведут на archive.org, сайт loopback.ru больше не работает). Я очень благодарен Илье Гозу за этот текст, и судьбе за то, что привела меня к нему в самом начале - вполне возможно, что без этого я бы прошел мимо Спиральной динамики. И я рекомендую всем интересующимся эту статью прочитать, там немного. И если кто знает, где об исследованиях Грейвза можно прочитать подробнее, просьба мне написать.

Дополнение. Через несколько месяцев после написания статьи были найдены следующие интересные материалы.

http://www.cruxcatalyst.com/2013/09/26/spiral-dynamics-a-way-of-understanding-human-nature/ - изложение теории, в статье много ссылок на другие сайты с материалами, в частности, на сайт Грейвза
http://www.clarewgraves.com/source_content/WSP_cc_edit.html Статья на сайте Клера Грейвза, начинается изложением истории исследований. Выступление Грейвза в 1971 записал William Lee, в 1998 Кован дополнил на семинаре, опубликовано в 2002. Возможно, именно она послужила источником для описания Ilya Goz.
На сайте Клэра Гейвза лежит список публикаций http://clarewgraves.com/articles.html, в числе которых - статьи в реферируемых журналах и выступления на конференциях.

Мышление моделями как базовая компетенция (ЛАФ-2018)

2018-06-18T12:50:39Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Совместное выступление с Ириной Суровой на ЛАФ-2018

Выступление на сайте конференции
Видео - на странице доклада.

Умение выделить словарь терминов предметной области, представить предметную область через диаграмму классов, а бизнес-процессы - на диаграммы активностей имеют под собой базовую компетентность мышления - способность быстрого, в темпе проекта, построения модели предметной области, потенциально незнакомой ранее, и далее - работать в этой модели, проектируя и реализуя изменения в этой области и процессов компании с помощью разрабатываемого софта. Модель надо уметь построить, сопрячь с отраслевыми, объяснять окружающим, сделав общей моделью проекта и достраивать в коммуникации. На этом основан не только DDD, но и большинство других подходов в IT, применять эту компетенцию можно не только в профессиональной работе, но и в любом взаимодействии с миром.
Но для начала эту компетенцию необходимо получить, в чистом виде ее не готовят, хотя необходимость фундаментальных курсов математики и физики в высшем образовании, а также ряда школьных предметов обосновывают именно этим.
В нашем совместном с Ириной Суровой выступлении мы надеемся выделить моделе-ориентированное мышление в чистом виде, и поговорить о подходах к его обучению. Примерно это же сейчас делает Анатолий Левенчук совместно с рационалистами, выделяя курс "мыслительного фитнеса", основ мышление на моделях как базу для курса системного мышления (https://thpectrum.livejournal.com/3514.html).

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

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

AgileDays-2009

2018-05-17T15:55:27Z

MaksTsepkov: Массовая правка: замена Категория:Конференции на Категория:AgileDays

Был на половинке конференции Ag;)leDays’09. Жаль, что не на всей.

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

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

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

Из интересного — говорят, у Асхата есть мапинг обязанностей «PMI->должности scrum» (или что-то в этом роде). Интересно это увидеть.

Максим Гапонов. Agile глазами менеджера: выбираем правильные очки. Опыт внедрения scrum в auto.ru, куда он пришел как менеджер отдела разработки. Проблема была в том, что разработка была сильно непрозрачна для заказчика, и потому было мнение — разработчики работают плохо. А сами они считали, что нормально работают. Внедрение постепенное и итеративное (по практикам), прозрачность была обеспечена. Заодно увеличилась скорость разработки, сначала — в 3 раза. 2 команды, архитектурная команда (как я понял, из тех же людей, супервизоры), продуктовая команда (стратегия и маркетинг). В компетенции менеджера осталось планирование активности и разработки, работа с командой, координация. Когда скорость выросла в 3 раза, выяснилось, что заказчик — не готов выдавать заранее, на итерацию. такой объем работ с достаточной проработкой, и все норовит свалиться к работе по меняющимся требованиям. Плюс срочные задачи. И это даже с недельными итерациями. В целом scrum для менеджера тяжелее, потому что надо больше думать. И требует изменений у смежников. Зато дает эффект.

Михаил Ганчиков. Scrum в Fixed-Price проектах: практический опыт. Не сначала. Опыт работы scrum в fixed-price разработке с фиксированными сроками на западного заказчика с заказной web-разработкой, интегрированной в его (заказчика) корпоративную систему. Заказчик хотел scrum, но с fixed price и сроками, с рисками на подрядчике. Проект не слишком большой, 4 месяца, 1 команда, 2 недели предварительная оценка. Аналитики были у заказчика, к оценке было 12 usecase, развернутые примерно в 20 историй, разной степени подробности и веса, 50-200 идеальных часов по предварительной оценке в показанных примерах. Они рассчитывали на команду 6 человек — 4 разработчика и 2 тестера. Дальше заказчику удалось продать 6 идеальных часов в день (фактор 0.75!), накладные расходы на scrum (планирование, ретро — 1 день/итерацию), месяц на стабилизацию версии, 10 % на обработку его хотелок по feedback (пытались 30, не вышло), 1.5 человека на управление (PO + 1/2 SM). А в стоимость часа заложили, что если команду придется увеличить в 1.5 раза (до 9) и еще кто-то останется на доводке по гарантии некоторое время, то все равно будет небольшой плюс. Хотя, быть может, что-то из написанного мною как проданное тоже заложили в стоимость часа — эту часть переговоров вел не докладчик. В целом по моим прикидкам заложенный коэффициент к оценке получается 2.5-3. Оценки в идеальных часах заказчик видел и верифицировал у третьих сторон и у себя внутри, в целом нормальные.

В результате на второй месяц команду увеличили до 9 человек, сроки получились на 3 недели больше, но в целом заказчик доволен. Выходных и сверхурочных не было, на команду сильно не давили. Заказчику сделали много дополнительных хотелок, ибо стратегический партнер. Но часть — против уменьшения первоначально заявленного scope. Manager, он product owner, помимо управления и приоритетов писал и поддерживал Accept test cases — от 2 до 25 на историю. В вики. Адская работа, так как требования уточнялись и плыли, хотя и не сильно. Часть кейсов программировали и проверяли автоматически. Заказчику отгружали релизами, он тоже тестил, посылал баги, feedback («а покрасьте отчет…») и change request (а еще выгрузку в excel надо). Change request — это объем работ, который оценивается и расширяет scope, оценки высылались и проверялись заказчиком.

Из практик — помимо daily scrum с заказчиком были ежедневные вечерние обсуждения (daily status) по ходу проекта, по ним — протоколы «минутки» (обязательно нужны!). Заказчику посылались метрики — сжигание оцененных историй. Иерархия разбиения — 3 уровня, usecase — истории-задачи (уровня реализации). На начальной оценке часть usecase была совершенно непонятна по объему (например, «перегрузить данные из старой системы»), так как выяснять было некогда, то их оценивали в некоторых допущениях, которые посылались вместе с оценкой. Заказчик или одобрял допущения, или возражал — тогда оценка менялась.

В целом так, может чего забыл. Интересно, но с нашими проектами, по-моему, не слишком соотносится, так как аналитика у нас внутри и это многое меняет. А по эффективности как-то близко получается…

Dan Rawsthorne. Who is your Product Owner, and what does he/she do? Увы, понимание разговорного английского оставляет желать лучшего… Но в целом было понятно и это интересно. Презентация — тренинг доя PO, но давались фрагменты. Если кратко, то PO — это Project Manager. В полном объеме. Со всеми правами, которыми он не должен злоупотреблять, так как команда — вещь тонкая. Но PO отвечает за продукт (подставляет свою шею). А еще он — team lead. И он — внутри команды. Снаружи есть еще Business Owner. А SM — лишь поддерживает процесс. По итогам итерации различается Sprint Review, которое с PO и Retrospective, которая без него. Дуализм PO — в своей роли и PO как член команды — есть. Но подробностей в эту сторону в голове не осталось. Из явного — он не участвует в некоторых мероприятиях.

Была упомянута RASCI-модель: Responsible — команда, Accountable — PO, Support — SM, Consulted — внешние эксперты, Informed — всех вокруг…

Презентовалась конструкция Scrum of Scrum — с реальной командой менеджеров продукта, в которой свои PO и SM, командами по разработке, и двумя виртуальными командами — PO и SM. Но без подробностей.

Показывалось разделение компетенций Business Owner (release goal, product roadmap, vision), Product Owner (продукт все внутри условий BO) и SM (организация команды).

Планирование — 4 уровня, Product — Capatibility — Stories — Tasks. Backlog — stories. Пример Capatibility для сайта — продавать билеты на самолеты, резервировать отели… Оценка story — size (small/medium/large) с коэффициентами, например, 2/4/8 для перевода в SP. И дальше — по опыту, мощность команды в SP. Для отбора в sprint — баланс Scope/Effort/Debt (вроде как новые фичи/исследования/долги). Tasks — на планировании, причем без PO (команда приняла Stories и сама его делит). Визуальный образ планирования — на доске, слева — backlog, правее карточки с невзятыми задачами. Может, идея прямо так и проводить, но явно это не высказывалось. Оценка задач — в идеальных часах.

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

Сурен Самарчян. Выявление и решение важнейших проблем компании. По исследованиям Гарварда, все сильно успешные компании (лидеры) отличаются от прочих наличием 5 вещей:

(1) есть система выявления проблем,
(2) есть подход (процедура) к решению, ориентированный на быстрое решение по низам, позволяющий взять ответственность,
(3) есть система информации (публикации) успешных решений,
(4) первые 3 пункта входят в обязанности менеджеров, причем
(5) на всех уровнях сверху до низу.

Процедуры в разных компаниях — различаются. Тойота 20 (30?) лет назад опубликовала свой, теперь его всячески изучают и пытаются использовать, но повторить с теми же результатми — пока не получилось. Сам Сурен про метод знал, но проникся — только на крутом тренинге в штатах с участием звезд. Метод называется «A3» — в честь специального бланка на формате А3, который надо заполнить по ходу решения и который концентрирует это самое решение. Требования на выходе — за 10 секунд человек, столкнувшийся с такой же проблемой должен опознать ее на бланке, и за 10 минут — понять, как надо решать. Тойота давно хочет перейти на А4, но пока не получается.

Области на бланке по памяти. В презентации все это есть и в инете, говорят, должно быть, но я не нашел.

Лица — владелец проблемы (ответственный) и куратор. Background (задерживаются релизы). Current State (текущий задержан на 2 недели). Корень проблемы. Контрмеры по проблеме в моменте. Изменения стандартов, чтобы исключить проблему в будущем. Заполняется, естественно, по мере решения.

Для поиска корня — искать причину. Можно применять метод «5 почему». Можно — рисовать графы причинно-следственных связей, там будут циклы, а будет — коревое влияние. Пример графов — показывал, но быстро. Контрмеры — всегда эксперимент, сколько бы времени не потратили на планирование. Придумали, не получилось — анализируйте. придумывайте дальше. Когда контрмеры провалились — самый сложный момент для директора и менеджера, всегда найдется пол организации, которые будут говорить «ну вот, мы же говорили — не надо ничего менять, а это — особенно».

Принцип поиска — задавайте вопрос «почему», а не «кто». Даже если этот кто — виноват реально. Потому, что тут же есть вопрос «если этот кто создает такие проблемы, то почему он здесь работает».

При внедрении таких, или аналогичных практик — нужно участие первых лиц, лидеров. Если поручают тому, кто свободен — обречено на провал.

Интересно и полезно. Лист стоит найти.

Software Best Practices-2007

2018-05-17T15:35:47Z

MaksTsepkov: Новая страница: «<blockquote> Конференция Software Development Best Practice прошла в 2007 году. Сайт конференции http://www.sdexpo.ru/ уже…»

Конференция Software Development Best Practice прошла в 2007 году. Сайт конференции http://www.sdexpo.ru/ уже недоступен, но анонсы остались: один и другой. Далее - мой отчет о конференции, опубликованный тогда внутри компании - публичного блога у меня еще не было.

Я был на втором дне. В принципе шел на первый трек, но не учел, что часть докладов по сути совместные, так что в целом больше был на втором треке, а не на первом. К сожалению, отчет пишу через почти две недели, но как сложилось.

Ключевая вещь, которая заинтересовала и вдохновила - Agile programming и ее проявления в виде extreme programming, scrum и композитных методов. Для меня, собственно, было ново и интересно выступление менеджеров, команды которых практически используют эти методики в реальных успешных проектах. В том числе сертифицируя их применение по ISO 9000. А это означает, что имеются готовые технологии и методологии, и можно основываясь на них строить процесс производства. На уровне общих слов они сильно пересекаются с прогрессивной частью имеющихся у нас в компании методик и тенденций, однако тут важны нюансы и комплексность подхода. Поэтому было бы интересно оценить, и, возможно, претворить в практику. Во всяком случае, правильно изменения в нашей компании вести в этом русле, а не вопреки ему.

Далее по докладам.

Bruce Eckel: Набор концептуальных фрагментов, посвященных путям программирования и месту человека в этом процессе. Такая вот мозаика, ну он мэтр, может себе позволить. Воспроизвести не берусь. Из основных мыслей: смотрите по сторонам, на побочные ветви процесса, там бывает много интересного.

Simon Monk, Momote ltd: Доклад по Agile Programing в виде Extreme programming. Основная идея - это хорошо и применимо на практике. У них небольшие этапы или проекты: 10 дней маленький, 20 - средний, 40 - большой. Это астрономический срок разработки, к этому есть стандартные времена на постановку (2-4-5) и на внедрение (3-4-5). Группы по 7 человек - менеджер, 4 разработчика, 2 тестера. Реально используют парное программирование. Говорил, что много чего меряют по самому процессу разработки и внедрения, считают структуру затрат на проект, представляют ее заказчикам.

Alexey Kovyazin GodeGear: Развитие software, 1 трек. Достаточно полный и скучноватый обзор истории развития ПО для PC, хоть и вызвавший (у меня) воспоминания по прошлому. По современным тенденциям - слабо. Очевидное противостояние .Net и Java как платформ, и как стоящих за ними корпораций, с рассуждениями, что может они договорятся, а может - нет. Но была интересная мысль, что действительно новые решения. определяющие тенденции. всегда рождались не внутри гигантов, а приносились со стороны, после чего кто-то из гигантов это, как правило, перекупал и далее развивал. То есть идеи приходят сбоку. А еще очевидная мысль, что разработчики не лояльны, и выбирают средства по текущему состоянию, а не за исторические заслуги.

Круглый стол по Agile: Участники (StarSoft, Motorola в России, Artezio) - действующие менеджеры компаний, в которых успешно все это применяется. Собственно, этим и интересно, хотя сам разговор - не очень. Они обсудили некие темы по практике применения этих методик. Из интересного - сертификация этого процесса по стандартам ISO, то есть можно вынимать нормативно положенную документацию и метрики, характеризующие качество процесса, не взирая на его экстремальный характер. Звучала цифра, что применение SCRUM удваивает производительность по сравнению с традиционными методиками. По оплате - уход от fixed cost к target cost, с делением рисков пополам с заказчиком.

Bertrand Meyer: К полностью автоматическим тестам. Доклад хорошо описал Игорь Беспальчук в своем отчете, и я не вижу смысла повторяться. Хотя меня как программиста всегда интересовало тестирование, выходящее за рамки модельных примеров, с которыми и так все понятно. И тут мне не очевидно, что из автоматических вызовов может нечто разумное получится.

Olga Ananko, Security testing: Увы, оказалось что это Web. Хотя на уровне общих слов все это применимо всюду, но с нашей практикой связано слабо. То, что они тестируют - понятно. Это ввод неверных параметров, попытки сделать незаконные по бизнесу действия или превысить границы своих прав. Я надеюсь, что наши тестеры тоже это делают, но далеко не уверен. Во всяком случае, судя по широкому и произвольному предоставлению прав в СМ, это не является большой заботой заказчика. Но конкретные примеры в докладе ограничивались Web-приложениями, и это не интересно.

Roman Elizarov: Практически доклад был о некоей системе обработки сообщений, которая должна переваривать их со скоростью до 1 млн. сообщений в секунду. Причем очень важно было избежать катастрофического падения производительности при превышении каких-то порогов. Очень интересно рассказанный, были убрана специфика конкретной системы и оставлена методологическая суть. Первое - не надо использовать MiddleWare. Потому что они реализуют некий сложный стандарт, который по природе не может быть быстрым и давать более 10K сообщений. При этом в конкретном приложении полный функционал этого стандарта обычно не нужен, на чем и экономим. Второе - если нужна хорошая производительность, это надо закладывать в архитектуру. Показаны два тонких места - синхронизация, то есть переключение процессов, и выделение памяти, которое надо мерить со сборкой мусора, а не отдельно. Ну и соответственно, как пример: для обработки сообщений оптимален типовой шаблон с итератором, позволяющий обрабатывать их пачками с внешней или внутренней синхронизацией не по каждому сообщению, и не диктующий способа выделения памяти. В общем, шаблоны полезны не только по стилю, но и по сути. Кстати, с выделением памяти: свой пул объектов, скорее всего, будет медленнее стандартного, он может быть полезен только для больших объектов, а никак не для скорости. Они добились требуемого 1M сообщений, ограничением стала 10Mb сетка, которую они грузят полностью.

Sergey Belov, StarSoft: Guerilla XP. Что делать, если заказчик не хочет extreme, а команда работает именно так. Тогда менеджеру приходится работать за заказчика. Ну и рассказывался пример проекта, история 2.5 года, 18 итераций, 17 человек команда, сейчас 1500 пользователей. По срокам итераций: ошибались пару раз на пару дней для месячной итерации. Сложнее всего - аналитику, так как он фантазирует. При планировании итерации оставляют резерв для изъятия, чтобы заменить это доработками, если аналитик не угадал. плюс усиливают команду тестеров, она тоже работает за заказчика. Используется парное программирование, задания режутся по дню, пары каждый день меняются. Плюс используется карусельный codereview - один программист из команды смотрит и рецензирует заливки за день, плюс тех.лидеры соседей. Общая идея: у программиста 3 продуктивных часа в день, пусть эти три часа он и программирует, но остальное время он тоже может приносить пользу. Используется ежедневная сборка и проверка - unit test, module test + high level test. Как-то так.

Собственно, все. На закрытии - ничего интересного, кроме Мейера. Который призвал осторожнее относитьcя к словам гуру и не применять методики, сделанные для обеспечения работоспособности индийских команд, в России бездумно.

Решаем проблему заказчика, а не слепо выполняем задание (AnalystDays-8 2018-04)

2018-04-27T08:05:07Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Выступление 27.04.2018 на AnalystDays-8
Доклад на сайте конференции, там ссылка на видео за 1$ (есть подписка)

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

В докладе я расскажу о том, как это сделать, и приведу примеры, как меняются пути решения после погружения в бизнес-замысел проекта.

Solving the client’s problem rather than blindly doing the task

Clients often accompany their request for new features with an idea of what exactly it is necessary to develop. Performers, in their turn, embark on designing the features required immediately, without finding out what problems they are supposed to solve. As a result, the solution developed does not meet the client’s expectations, and this may be due to several reasons. First, the customer’s idea may not be relevant to his situation initially. Secondly, the solution may turn out to be wrong because of the details of the implementation. Thirdly, it happens that the task can be accomplished faster and easier. For this reason, the analyst should define the client’s problems as early as on the first stage of the project.

My presentation demonstrates how it can be done and provides the examples of how the immersion into the business plan of the project changes the ways of solving the problem.

Тесты по Спиральной динамике

2018-04-22T11:55:45Z

MaksTsepkov:

Мой тест по спиральной динамике: 87% бирюзового, 77% желтого и 75% оранжевого. Я прошел на http://jobEQ.net 13.10.2013, только заинтересовавшись системой - чтобы получить чистый результат. Тест тогда был доступен бесплатно на русском для личного использования. К сожалению, в России его начали активно и статистически заметно использовать для оценки персонала, а эта опция - платная, поэтому русский вариант закрыли, а английский вроде по-прежнему в бесплатном доступе есть. На GoEvolution-2016 я общался с Анной Ивановой, которая переводила его и является представителем в России, и она обещала поспособствовать интересующимся пройти тест за небольшие деньги.

В феврале 2019 Анатолий Баляев, переводчик книги по Спиральной динамике, популяризатор и евангелист этой теории в России, тренер и консультант, использующий эту теорию на практике, опубликовал для общего использования созданный им тест. Тест был качественный, и не только выдает результат по цветам, но и ряд других характеристик. К сожалению ключевое слово тут - был. Тест был доступен на test.spiraldynamics.ru, а сейчас (01.2024) домен не доступен, а spiraldynamics.ru стал перенаправлением на spiraldynamics.pro. На этом сайте есть два других теста: по корпоративной культуре и по струнам первого порядка - какое счастье вам отзывается. А исходный тест, насколько я понимаю, больше недоступен. Жаль. Вот как это выглядело (archive.org). Интересно, что archive.org показывает не только тест, но и мой результат.

Про другие тесты, которые я проходил. Тест из Школы жизни все-таки очень поверхностный. http://sdtest.ru - он лучше, особенно потому, что выбирается несколько ответов, а не один. Но оба теста не слишком хорошо различают старшие цвета, желтый и бирюзовый. Они считают, что на бирюзовом непременно думаешь о целях всего человечества сразу. А это не так, это на зеленом от человека до счастья человечества один шаг, потому что все вместе делают дело в плоской организации (движении). А на желтом и бирюзовом организации сложные (у Лалу ясно видно). А разница в том, что на желтом ты мыслишь рамками и целями своей организации, не слишком большой, а на бирюзовом границы организации становятся полупроницаемыми, а цели начинают вырабатываться совместно, внутри и снаружи. В посте на FB насыпали еще ссылок, но их я не проходил.

Целостное представление деятельности предприятия на диаграммах учета (Соколовские чтения-2018))

2018-04-19T18:44:00Z

MaksTsepkov:

Целостное представление деятельности предприятия
через потоки ресурсов отражаемые на диаграммах учета
Integrated reflection of the business as resource flow, presented on the accounting diagram
Соколовские чтения «Бухгалтерский учет: взгляд из прошлого в будущее» Санкт-Петербург, 19-21.04.2018

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

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

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

Доклад является развитием моего доклада на Соколовских чтениях 2017 года, в котором были показаны общие принципы организации диаграмм учета. Я надеюсь, что доклад позволит участникам конференции начать применять такие диаграммы в своей профессиональной деятельности.

Agile и другие новые технологии управления для организации работы креативных команд (KazanEventExpo-2018)

2018-04-11T19:52:29Z

MaksTsepkov:

Выступление 12.04.2018 в рамках Kazan Event Expo

В выступлении был развернутый рассказ, аннотацию которого можно прочитать на странице категории, а краткие версии можно посмотреть в выступлениях Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11) и Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017)

Скачать весь pdf

Применим ли новый менеджмент в логистике (Конгресс по логистике 10.04.2018)

2018-04-09T22:14:54Z

MaksTsepkov:

Еще про новый менеджмент

Первый Конгресс руководителей и специалистов по логистике и цепям поставок компаний — производителей и ритейлеров 10.04.2018

Подробное изложение можно посмотреть в докладах Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11), Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017) и Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017). Более поздние материалы - статья «Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции» и серия статей «Менеджмент цифрового мира», позднее опубликованная в виде книги «Менеджмент цифрового мира», а для тех, кто предпочитает слушать - доклад Эволюция технологий управления (ПИР Сибирь-2019).

Скачать весь pdf

Самоуправление как технология менеджмента четвертой промышленной революции (ЦЭМИ 10.04.2018)

2018-04-09T21:40:36Z

MaksTsepkov:

Выступление на круглом столе на Всероссийском Симпозиуме «Стратегическое планирование и развитие предприятий»
Центральный экономико-математический институт РАН 10.04.2018 Видео ожидается.

Прозрачность движения к результату в Agile для руководства (CodeFest-2018)

2018-04-01T02:49:37Z

MaksTsepkov:

Доклад на CodeFest-2018 31.03-01.04.2018 в Новосибирске
Доклад на сайте конференции (вместе с презентацией и видео)
Видео на youtube

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

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

Ссылки по OMG Essence

2018-03-25T18:58:24Z

MaksTsepkov:

Страница стандарта http://www.omg.org/spec/Essence/, доступен только в виде pdf

В стандарте, помимо языка, приведены следующие полезные примеры.

Методы:
- Scrum - раздел E.2.2
- Waterfall - раздел E.2.4
В разделе E.2.5 - варианты lifecycle для разных видов проектов и сопровождения
Способы расширения
- Что меняется в Scrum, если использовать User Story вместо абстрактных Product Backlog Item E.3.1 и E.2.3
- Добавление Business Analysis и нужд стейкхолдеров - A.2

Practice Library от Ивара Якобсона https://practicelibrary.ivarjacobson.com/ содержит описание большого количества методов в формализме OMG Essence. Для доступа требуется бесплатная регистрация. Ссылки дальше ведут на корневые страницы, и надо проваливаться вглубь за подробностями

Agile - https://practicelibrary.ivarjacobson.com/content/agile-essentials
SAFe - https://practicelibrary.ivarjacobson.com/content/agile-scale-essentials, включая работы с архитектурой, управление продуктом и многое другое
Некоторый вариант итеративного RUP - Essential Unified Process https://practicelibrary.ivarjacobson.com/content/essential-unified-process
- В нем отдельно интересны UseCase 2.0 https://practicelibrary.ivarjacobson.com/content/use-case-20-essentials-publication

Методы Agile и бирюзовых организаций для организации работы креативных команд (лекция 03.03.2018 ВШЭ СПб)

2018-03-03T08:12:49Z

MaksTsepkov:

Гостевая лекция Методы Agile и бирюзовых организаций для организации работы креативных команд 
прочитана 03.03.2018 в рамках майнора Высшей Школы Экономики в Санкт-Петербурге

В связи с отключением электричества видео не сохранилось. Поэтому можно смотреть доклады

Анонс на сайте ВШЭ
О конструкции новых управленческих технологий и о том, как они отвечают на вызовы нового мира, включая приход нового mindset поколения соцсетей в своей лекции будет рассказывать Максим Цепков http://mtsepkov.org/Agile, IT-архитектор и бизнес-аналитик, эксперт и навигатор по миру Agile и Спиральной динамики.
Грядущая промышленная революция положит конец современному индустриальному обществу, что приведет к переосмыслению ценностей и новым способам управления общества и бизнеса. Это предсказал Элвин Тоффлер в книге «Третья волна» в далеком 1980 году. Прошло почти 40 лет, и сейчас новые способы организации бизнеса уже не являются каким-то неопределенным будущим, они оформлены в конкретные новые технологии управления: методы Agile, возникшие в IT-отрасли более 15 лет назад, технологии бирюзовых организаций, игрофикацию. О конструкции новых управленческих технологий и о том, как они отвечают на вызовы нового мира, включая приход нового mindset поколения соцсетей в своей лекции будет рассказывать Максим Цепков (http://mtsepkov.org/Agile), IT-архитектор и бизнес-аналитик, эксперт и навигатор по миру Agile и Спиральной динамики.
Приходите на лекцию! Вам жить в новом мире третьей волны и применять эти технологии в действии!

Будущее уже наступило: от Agile к Бирюзовым организациям (Серебряный Лучник-2018)

2018-02-13T18:44:31Z

MaksTsepkov:

Серебряный Лучник - академический день
Анонс выступления 
14.02.2018, Москва, факультет журналистики МГУ

Третья промышленная революция, которая была предсказана в далеком 1980 году Элвином Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них - практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире.

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

За пределами IT-отрасли тоже формируются ответы на вызовы нового мира. Фредерик Лалу в книге «Открывая организации будущего» представил результаты исследования новых организаций в самых разных отраслях, выявил общие механизмы и практики, которые лежат в основе управления их деятельностью. Он показывает, как устроены организации, объединяющие много независимых лидеров, движущихся к общей цели организации и координирующих движение. Распространение бирюзовых организаций - зримое проявление изменений mindset в современном мире.

В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь. Доклад является развитием моих выступлений по темам Agile и Спиральной динамики, доступных на моем сайте http://mtsepkov.org/Agile

CustIS Accounting (1998)

2018-02-06T08:34:27Z

MaksTsepkov:

CustIS Accounting — передовая технология автоматизации учета и анализа финансово-хозяйственной деятельности

Рахтеенко В. Е., Хомюк С. В., Цепков М. А.

Статья рассказывает историю создания ядра CustIS Acconting и распределенной АБС на его основе для ЛипецкКомБанка (ЛКБ) примерно за полгода в 1997 году. Работы вызваны изменением с 01.01.1998 банковского плана счетов бухгалтерского учета и ЛКБ принял решение заказать новую систему CUSTIS. Работы начались летом 1997 года, а 1 января система была запущена в боевую эксплуатацию на серверах всех филиалах банка с репликациями метаданных и документов.
Статья опубликована в журнале «Компьютер в бухгалтерском учете и аудите» 2-1998.

Сейчас на рынке представлено множество (так и хочется добавить несчетное) программных продуктов, которые позиционируются как «средство для комплексной автоматизации предприятий».

Если Вы почитаете рекламные материалы и поговорите с персоналом фирмы, производящий продукт, то с некоторым раздражением заметите, что все предлагаемые продукты на первый взгляд одинаковы: все «идут от документа», все «работают в технологии клиент-сервер», практически все имеют версию системы, работающую на Oracle и т. д.

«Ну хорошо», — говорите Вы, — «а как обстоит дело с предметной частью? Какая именно система лучше всего удовлетворяет именно мои потребности?». Ответ на этот вопрос, возможно, также вызовет Ваше недоумение — с первого взгляда буквально во всех системах есть все, что Вам нужно и даже больше того, что нужно.

Все эти недоумения рассеиваются несколько позже. При более внимательном рассмотрении Вы начинаете понимать, что под терминами «клиент-сервер», «документы» и даже «технологии Oracle» часто понимаются достаточно разные вещи. Что же касается предметной части, то нередко вы убеждаетесь, что предлагаемая Вам система не полностью отвечает (или полностью не отвечает) Вашим потребностям. Естественно, сразу встает вопрос о доработке продукта конкретно для Вас, и бойтесь тех, кто скажет, что это дешево.

Тяжела задача авторов этой статьи — надо Вас как-то убедить, что предлагаемая система CustIS Accounting (действительно одна из многих-многих), решает конкретный класс задач лучше, чем кто-либо другой. Исходя из этого, определим вначале такие задачи, а потом (куда деваться!) — начнем по косточкам разбирать, какими характеристиками должна обладать система, чтобы такие задачи решать хорошо, и как эти характеристики реализованы в CustIS Accounting.

Зная на своем опыте, как тяжело вникать в объемные теоретические построения, мы решили построить изложение материала на живом примере.

Кроме этого, последняя треть статьи посвящена изложению примера реализации в CustIS Accounting конкретного документа.

Технология согласования некоторых алгоритмов с архитектурой векторно-конвейерных ЭВМ (Вопросы Кибернетики 1987)

2018-02-06T01:00:20Z

MaksTsepkov:

Разбирая старые книги обнаружил журнал со своей первой статьей «Технология согласования некоторых алгоритмов с архитектурой векторно-конвейерных ЭВМ», написанной в соавторстве в далеком 1987 году в сборнике «Вопросы Кибернетики». Статья посвящена реализации алгоритмов на Советском аналоге Cray-1, который, правда, так и не был воплощен в железе, но на эмуляторе которого на БЭСМ-6 я работал, начиная с первого курса в институте. Сначала писал реализацию элементарных функций — квадратный корень и экспонента, и эти реализации были включены в официальную библиотеку. Но о них я рассказывал на студенческой конференции МФТИ, печатной статьи не было. А эта статья вышла уже на третьем курсе, и моя часть — библиотека макросов для макроассемблера, которая позволяла писать структурные операторы — циклы, if-then-else и другие.
На картинке - обложка журнала и начало статьи, если перейти - можно посмотреть скан статьи целиком.

IT-источники знаний о мышлении

2018-01-27T23:47:39Z

MaksTsepkov:

Оригинал в ЖЖ, сообщество thpectrum

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

После этой преамбулы перехожу к идеям.

1. Разработка софта, включая написания кода - чистое мышление, соответствует этапу проектирования (НИОКР) для других отраслей деятельности (например, разработки самолетов). Тезис - старый, насколько я знаю, был впервые сформулирован Ривзом (Reeves) в 1992 в статье http://www.developerdotstar.com/mag/articles/reeves_design.html (перевод http://lib.custis.ru/Reeves). Но при этом результаты этого мышления непосредственно зафиксированы в коде программ. Об этом свидетельствует закон Конвея (https://en.wikipedia.org/wiki/Conway's_law), гласящий что структура системы соответствует структуре коммуникаций в команде, которая разрабатывала эту систему. Таким образом, в коде софта мы можем наблюдать результат коллективной мыслительной деятельности команды разработки. А практика хранения кода в системе контроля версий позволяет прослеживать не только текущие результат, но и логику развертывания этого мышления во времени. Если к этом добавить концептуальный слой проектирования, история которого зафиксирована в версиях вики, а также сопутствующую этому переписку в таск-трекере, которая содержит основания для изменений в коде, то получается большой массив первичных данных для исследования мышления. При чем он доступен в исходном виде для большого количества открытых проектов самого разного размера. При чем это мышление касается практически всех областей деятельности человека, а так же физического мира, поскольку все они в той или иной мере поддержаны и воплощены в софте.

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

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

2. Эрик Эванс, разрабатывая DDD (Domain Driven Design, https://en.wikipedia.org/wiki/Domain-driven_design) в своей концепции ограниченных контекстов перенес шаблоны проектирования объектно-ориентированного подхода (ООП) на онтологическую работу - построение понятийной модели предметной области (домена). При этом сформулировал, что прежняя практика построения единой и непротиворечивой модели и связанного с ней понятийного аппарата является слишком сложной для реализации в темпе проекта (как и построение монолитного софта), и потому онтологии предметной области должны быть модульными, с точками расширения, и следует применять для их построения те же приемы, которые наработаны для построения софта в ООП (наследование, библиотеки общих частей, изоляция разных областей, инкапсуляция и т.п.). Последующее развитие DDD показало, что именно это является наиболее ценной частью концепции. Но сформулировано все это на языке IT и для IT-инженеров, и, как водится, It-шники не слишком заботятся о том, чтобы обратным ходом попробовать включить это в "большую науку", переформулировав в принятых там терминах и связав с другими концептами. Мне кажется, в рамках формулирования курса могло бы быть интересным подумать о включении в него и этой составляющей тоже.

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

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

4. Частным, но важным проявлением такой аналогии я бы полагал изменения, которые сейчас происходят в lifecycle профессиональной деятельности человека. Если раньше она разворачивалась преимущественно в водопадной модели: школа - институт - работа по профессии, а смены профессии или дополнительное образование были редки и, скорее, исключениями, то сейчас она переходит к итеративной работе, непрерывному образованию на протяжении всей жизни. Если образование рассматривать как фазу проектирования (фрагмента) софта-человека, а работу по специальности - как фазу кодирования, и дальше сформулировать те изменения, которые принес Agile в разработку как изменения, которые произойдут с профессиональным путем человека, то. как мне кажется, можно получить достаточно интересную картину. Понятно, что такая штука имеет ограничения, как всякий межотраслевой перенос шаблона, но она позволит сформулировать ряд гипотез о будущем, с которыми далее работать - поскольку переход на Agile уже произошел и последствия доступны для анализа, а вот изменение профессионального пути еще только разворачиваются. Эта метафора уже в лежит стороне от создания курса по мышлению, однако она касается изменений, которые сейчас происходят в надсистеме (через пару уровней) и потому может быть интересной.

На этом - все. Текст получился достаточно длинным, и, возможно, для обсуждения его следовало разбить на несколько постов, так как пункты слабо связаны. Но поскольку я не очень знаю, насколько все эти идеи будут интересны в сообществе, пусть будет один пост.

Как строить свой профессиональный путь - схемы самоопределения (TeamLeadConf-2018))

2018-01-27T07:25:16Z

MaksTsepkov:

Еще про самоопределение

Выступление на TeamLead Conf 8-9.02.2018 в Москве 
Доклад на сайте конференции
Пост на FB
Видео, о докладе рассказано в числе других в посте о конференции на хабре
В 2022 доклад был доработан Как строить образ будущего и идти к нему - схемы самоопределения (Saint Teamlead-2022) и Самоопределение: чего я хочу от жизни и работы (SQAdays-2023) и написана серия статей в Категория:Самоопределение

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

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

Рассказ будет новой версией моего весеннего доклада Самоопределяйся технологично!

Дополнение. Тема развивается, следующая версия Как строить свой профессиональный путь - схемы самоопределения в QA-контексте (COMAQA-2018), а на Saint TeamLeadConf-2019 был практикум Строим свой профессиональный путь - без видео, но слайдов больше и есть слайды про применение схем для семьи. Существенное расширение на AnalystDays-2022 Как строить образ будущего и идти к нему с фокусом на создании вдохновляющего образа будущего, и по тем же слайдам был доклад на конференции школы Левенчука с фокусом на конструкцию схем самоопределения. Тема развивается, текущее состояние смотри Категория:Самоопределение.

Управление знаниями: какие документы нужны и что в них фиксировать (TeamLeadConf-2018)

2018-01-27T07:20:33Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Выступление на TeamLead Conf 8-9.02.2018 в Москве 
Доклад на сайте конференции
Расшифровка доклада в статье на habr
Пост на FB

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

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

Долговременная документация проекта тоже служит коммуникации: ты-нынешний с тобой-будущим, которому надо быстро вспомнить контекст; ты и пользователи системы и другие.

Подход к проектированию документации аналогичен проектированию интерфейсов: описываешь кейсы коммуникаций, определяешь, какими документами и артефактами это обеспечивается, понимая, что каждый документ имеет свою цену, и потому часть можно оставить в головах людей. И только после определения документов стоит выбирать, какими инструментами пользоваться: Wiki, Google Docs, что оставить в Task tracker и так далее.

Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM).

В целом доклад развивает мое выступление Agile и управление знаниями в ИТ-проектах на конференции KM Russia 15-16.12.2016.

Agile: что надо знать аналитику, чтобы действовать?

2018-01-21T20:58:19Z

MaksTsepkov:

Мастер-класс на сайте конференции
Видео на vimeo

Достаточно регулярно слышишь вопросы, подобные следующему: "У нас в проекте Scrum, мне надо писать тест-кейсы для тестировщиков, и я не понимаю, откуда брать информацию." Когда начинаешь обсуждать, то часто выясняется, что под словом "Scrum" в проекте понимают некоторую оригинальную конструкцию, при этом спрашивающий точно уверен, что именно это - и есть Scrum. Между тем, Scrum и другие Agile-методы - нормированная конструкция, о которой можно прочитать документы, и из которых можно вывести ответы на этот и другие вопросы. Но я не буду представлять документы. Я покажу, как мыслить в логике Agile mindset, получая ответы на этот и другие вопросы. При условии, конечно, что такие ценности Agile-манифеста, как работающий софт, сотрудничество с заказчикам и другие не представляются пустым звуком. Покажу на реальных кейсах от слушателей, решая их проблемы.

Это - не доклад, а мастер-класс, на котором после короткого введения я разбирал кейсы от участников. За полтора часа получилось разобрать 6 кейсов, и удовлетворены были не только их авторы, но и другие участники, которые с интересом слушали происходящее.

Кейсы, которые разбирали (с доски):

Продукт ведут 4 команды: бэкенд и три фронтенда для Web, iOS и Android. Как синхронизовать разработку и поставку фич
ERP-разработка, 5 разработчиков, 3 тестировщика, 1 аналитик, который сильно перегружен. Какие есть варианты решений?
Web-сервис продажи билетов, более 4 лет с релизами раз в квартал. Внутренний заказчик все время меняет требования, что делать? При этом многие фичи - экспериментальные
Продукт разрабатывает команда 150 человек в 10 локациях, группы разделены по stream, 6 аналитиков в разных локациях. Как построить коммуникации? Как держать общее видение?
Команда - 8 человек в разных городах, 1.5 аналитика. Где границы детального проектирования?
У нас типичная ситуация: заканчиваем спринт, часть задач сделано. но не протестировано. Как с ними быть, как организовать Agile-процесс?

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

Agile: что надо знать аналитику, чтобы действовать? from Vlad Orlikov on Vimeo.

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

Скачать весь pdf

UX: делаем систему удобной? - Нет. Делаем удобной жизнь! (WIAD-2018)

2018-01-20T12:31:44Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Доклад 24.02.2018 на площадке World Information Architecture Day (WIAD) 2018 в Санкт Петербурге, которую организует SPb UX (анонс, программа). Видео выступления.

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

Agile и другие новые управленческие технологии (EFEA-2018)

2018-01-19T08:50:59Z

MaksTsepkov:

Выступление 19.01 Санкт-Петербург Europa + Asia Event Forum

Записи выступления на конференции не было. Но можно посмотреть записи других выступлений но этой теме. Последние на момент публикации - Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11) и Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017), а также Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017)

Скачать весь pdf

AgileVsGamesOtumka

2017-12-16T18:23:52Z

MaksTsepkov:

Презентация с моего выступления в ОТУМКА 16.12 Agile и игрофикация: за каким менеджментом будущее?

Этот доклад был расширенной версией Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017)

Для истории: отзыв и фото Дмитрия Колчина

Скачать весь pdf

Agile для тех, кто хочет разобраться: что он дает для управления проектом и на какие современные вызовы отвечает (PMonline 2017-11)

2017-11-25T13:32:11Z

MaksTsepkov:

Выступление на online-конференции Управление проектами в малом и среднем бизнесе 25.11.2017
Все материалы доступны на сайте конференции

Agile и бирюзовые организации - два пути менеджмента в мир третьей волны (Круглый стол в SPb 2017-11)

2017-11-24T15:27:22Z

MaksTsepkov:

Круглый стол «Agile и бирюзовые организации» 24.11.2017 в Открытой школе бизнеса в Санкт-Петербурге
Видео на youtube

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

Agile: зачем стоит применять его методы и как именно (GoEvolution-2017)

2017-11-20T20:24:25Z

MaksTsepkov:

Беседа с Ольгой Гусевой 16.11.2017 на беcплатной online-конференции Великая октябрьская эволюция, которую проводит Анатолий Баляев. Тема — «Agile: зачем стоит применять его методы и как именно».

В современном мире любой успешный тренд покрывается густой пеленой мемов, люди начинают ожидать от него волшебных решений — а потом разочаровываются. Agile — не исключение. Между тем, он появился в IT как средство решение конкретных управленческих задач, с которыми не справился классический менеджмент, и за 15+ лет развития доказал свою успешность — если его методы применяются по назначению. И сейчас он идет в другие отрасли — не потому. что «можно», а потому, что новые вызовы третьей промышленной революции добрались до них. Я расскажу, на какие вызовы и как именно отвечает Agile, какие задачи бизнеса он решает.

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

В конференции я участвовал третий раз. Конференция преимущественно идет почти месяц по вечерам, но есть и offline-мероприятия. Все записи этого и прошлых лет доступны на сайте конференции, смотрите, там много интересного.

Видео беседы https://youtu.be/pwSFOiGp1LA

Работа с конфликтами и ответственностью в сообществах многих лидеров (GoEvolution-2017

2017-11-20T20:09:01Z

MaksTsepkov: добавляем новую категорию

Беседа с Анатолием Баляевым 24.10.2017 на беcплатной online-конференции Великая октябрьская эволюция, которую проводит Анатолий. Тема - «Работа с конфликтами и ответственностью в сообществах многих лидеров».

Одной из проблем сообществ, особенно если они включают ярких лидеров, являются попытки придти к единому мнению и все согласовать — это отнимает много времени и сил, и иногда даже парализует работу. Я делился практиками работы с ответственностью и конфликтами из холакратии и бирюзовых организаций, которые позволяют конструктивно решать эти проблемы. Часть из них была апробирована мною при консультировании разных организаций и сообществ и принесла пользу.

Видео беседы https://youtu.be/ay5rlgojBeA

Тестировщик и DevOps: позволяют ли интерфейсы системы эффективно решать инциденты? (SQAdays-22 2017-11)

2017-11-18T10:06:11Z

MaksTsepkov:

Еще про архитектуру

Доклад на SQAdays-22 19.11.2017
Видео https://vimeo.com/249366759

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

Отзыв Паша @Saint_qa прикольный доклад о devops. Докладчик супер и веселый )))))

Визуальные модели корпоративного приложения (Meetup в Райффайзенбанк 2017-11-01)

2017-11-01T15:00:26Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Мини-конференция Использование визуальных моделей в ИТ 01.11.2017
Отчет со всеми видео и презентациями https://habrahabr.ru/company/raiffeisenbank/blog/342890/ 
Видео моего доклада на youtube

При проектировании сложных корпоративных приложений эффективным является использование моделей, описывающих предметную область и само приложение в соответствии с подходом Domain Driven Design. При этом хорошая визуализация является непременным атрибутом модели. В выступлении обменяемся опытом построения архитектуры приложения с использованием трех основных моделей: доменной модели, представленной диаграммой классов, модели движения ресурсов, представленной диаграммами учета и модели документооборота на основе диаграммы состояний. Все это дополняется моделью бизнес-процессов на основе диаграммы деятельностей (activity diagram) и объединяется моделью архитектуры предприятия на основе Archimate, и дополняется метафорой системы в тех случаях, когда ее получается придумать. В рассказе будут приведены примеры диаграмм из реальных проектов.

Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017)

2017-10-26T22:04:53Z

MaksTsepkov:

Доклад на Agile Business Conference 26.10.2017
Видео на youtube
Расширенный вариант был в ОТУМКА 16.12

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

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

Это — развитие доклада на Российском игровом форуме «Южный РИФ-2017», которому был посвящен этот пост, частично раскрывающий содержание.

Отзыв Андрея Павленко: «#abc17 Максим Цепков Одно из лучших выступлений на конференции и один из лучших слайдов этого выступления. Присмотритесь особо к правой, нисходящей тенденции „адаптации“ Аджайла к незрелым уровням спиральной динамики — это же почти исчерпывающий справочник фейлов при „внедрении“ Аджайла :)» - на фото слайд 17 из презентации.

Бизнес-анализ: от абстрактного замысла до внедрения и дальнейшего развития ИТ-решения (Максим Цепков на SECR-2017)

2017-10-20T15:01:05Z

MaksTsepkov:

Еще про архитектуру

Доклад на сайте конференции
Доклад на 0x1.tv
Видео https://vimeo.com/240324403

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

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

Я расскажу о методах и практиках работы бизнес-аналитика на разных фазах жизненного цикла ИТ-решения, а также о качествах и компетенциях, которые позволят ему отвечать на новые вызовы.

Фото с доклада - Сергей Пчеляков

Удовлетворенность стейкхолдеров – два разных смысла (AnalystDays 2017-10 в Минске)

2017-10-14T07:20:45Z

MaksTsepkov:

Доклад на сайте конференции
Видео на vimeo

Когда говорят, что критерием успеха проекта вместо исполнения спецификации в заданный сроки и бюджет теперь является удовлетворенность стейкхолдеров, то многие думают, что они так и работают: в их компаниях давно нацелены на долгосрочные отношения с клиентами и выясняют степень их удовлетворения сотрудничеством. Однако, это - разные вещи, а в дискуссиях на конференции ТочкаСборки я понял, что эта разница не осознается, люди продолжают вести проектную деятельность в старых критериях качества. И решил сделать об этом краткий доклад на конференции, развивая свой пост Блог:Максима Цепкова/2017-09-12 Удовлетворенность стейкхолдеров - два разных смысла

Scrum - революционный метод управления проектами

2017-09-17T19:06:03Z

MaksTsepkov:

Статья опубликована на портале Национального банковского журнала (NBJ) 05.09.2017

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

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

Традиционные способы повышения производительности в ИТ-отрасли не работают. Это было ясно еще в 1980-х и хорошо обосновано в книге Тома ДеМарко и Тимоти Листера «Человеческий фактор: успешные проекты и команды» (1987). Впрочем, не все верят подобным обоснованиям, поэтому был проведен эксперимент по построению правильного процесса — так появился RUP. Он оказался очень дорогим и недоступным среднему и малому бизнесу и, как показал опыт, вовсе не гарантировал результата. В качестве ответа появилась альтернативная ветвь менеджмента для ИТ: Agile-манифест, декларировавший ценности и принципы, следовавшие из ключевой роли человеческого фактора в успехе проекта, и Scrum, давший организационный шаблон для реализации проектов в соответствии с ценностями и принципами Agile. Относительно недорогой и понятный: его могли применять даже не самые подготовленные команды. Без гарантии результата, зато с прозрачным представлением хода движения к цели — и этого оказалось достаточно.

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

Постепенно Agile-методы завоевали признание в ИТ-отрасли в качестве основного способа ведения проектов и организации текущих работ. Его научились представлять на советах директоров крупных корпораций, чтобы объяснить «бизнесу», почему именно ИТ-подразделение работает не так, как другие. Классические подходы, конечно, продолжали существовать, особенно в проектах с большими бюджетами, в частности, военных и государственных, обещая гарантированный результат и с завидной регулярностью не выполняя обещаний. В результате громких скандалов, последним из которых был скандал с ObamaCare, в ряде стран стали принимать решения об использовании Agile-подходов и в государственных проектах.

Сейчас Agile-методы выходят далеко за пределы ИТ-отрасли. Для многих картинка выглядит так, что эти методы, став зрелыми, постепенно вливаются в поток развития основного менеджмента, как представлено на рисунке 1. Собственно, такие попытки происходят с 2008, когда четвертая версия PMBOK попыталась включить итеративную разработку. Неудачно, прошлая целостность метода была утеряна, а новая — не возникла.

На самом деле эволюция пойдет совсем другим путем: лучшие практики классического менеджмента будут включены в Agile и расширят семейство его методов. Классика исчезнет. В ИТ это уже происходит, типичным примером является SAFe, предназначенный для масштабных и сложных проектов, требующих особого внимания к архитектуре решения.

Вымирание классических подходов не означает, что менеджеры, являющиеся их носителями, останутся без работы. Просто им придется измениться, восприняв новый набор ценностей и принципов. Поэтому с распространением Agile появляются отраслевые редакции Agile-манифеста: например, для маркетинга появляются адаптации Scrum или для образования eduScrum.

Agile приходит в другие отрасли не потому, что они тянутся перенять какой-то передовой опыт. Просто в эти отрасли сейчас приходят те самые вызовы, ответом на который явился Agile в ИТ и служат драйвером изменений: критическая роль человеческого фактора, которую повышает роботизация и диджитализация, потребность Business Agility. Но главным драйвером является изменение mindset человека, которое несут соцсети. Эти изменения были проанализированы в середине нулевых рядом исследователей, в частности, Гэри Хэмелом (Gary Hamel). Итоги исследования «The Facebook Generation vs. the Fortune 500», опубликованные в The Wall Street Journal показывают, что ценности и шаблоны поведения, с помощью которых достигается лидерство в соцсетях, противоречат тем, на которых основана успешная карьера в традиционных корпорациях. Однако люди умеют адаптироваться в сообществах, в которых приняты традиционные стереотипы поведения, но, когда их там становится большинство — перестраивают правила. Поэтому как только поколение, получившее mindset соцсетей еще в школе и институте, массово придет на работу — традиционные компании принципиально изменятся.

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

Россия в этом глобальном процессе занимает достойное место. Это видно внутри ИТ-отрасли, которая по способу организации адекватна мировому уровню. Видно по той скорости, с которой общество среагировало на прошлогоднее выступление Германа Грефа на Гайдаровском форуме, где он сформулировал, что за Agile и Scrum — будущее. Понятно, что процесс неоднозначный и противоречивый, впрочем, это свойственно любым крупным изменениям. Опыт Сбербанка и Альфа-банка, которые внедряют Agile не только для ИТ-проектов, но и для работы бизнеса в целом — широко известны.

Наконец, заметно движение в сторону гибких методологий в государственных проектах. Это началось еще до выступления Германа Грефа. Осенью 2015 года с AgileKitchen на территории Аппарата Правительства РФ и с участием его представителей. В прошлом году в рамках премии «Проектный олимп» была отдельная номинация по применению гибких методологий в госпроектах. В частности, был представлен интересный опыт Самарского пенсионного фонда по использованию Agile для организации работы и в частности, для выдачи материнского капитала, что позволило избежать очередей. В настоящее время это привело к организации отдельной экспертной подгруппы по применению гибких методологий при президиуме Совета при Президенте Российской Федерации по стратегическому развитию и приоритетным проектам.

Agile - ответ на вызовы нового мира

2017-09-17T18:58:42Z

MaksTsepkov:

Статья опубликована на портале Национального банковского журнала (NBJ) 28.08.2017

Гибкие методологии появились в ответ на новые вызовы третьей промышленной революции, которым не смогли дать ответ традиционные подходы к менеджменту. Основных вызова три: Business Agility — высокая гибкость бизнеса в быстро изменяющемся мире, цифровизация, замена регулярного труда роботами, которая ведет к обществу, управляемому знаниями, и возникновение новой конструкции мышления, новой mindset, требующей адекватной ей перестройки бизнеса.

Первой с этими вызовами столкнулась ИТ-отрасль с появлением персональных компьютеров. Гибкие методологии стали успешным ответом на них, появившись примерно в 2000-м году. Именно в ИТ стали накапливаться и формироваться практические методы, которые сейчас активно распространяются на другие отрасли. Чтобы понять, насколько целесообразно использование гибких методологий в конкретной организации, важно оценить силу проявления каждого из новых вызовов в разных отраслях и областях.

К примеру, Business Agility требует отвечать на постоянно и быстро меняющиеся условия функционирования организации. Для оценки силы ее действия можно использовать Cynefin Framework, традиционные методы функционируют в простом и сложном сегментах, а гибкие — в запутанном и хаотическом. При оценке следует учитывать динамику изменений, а не только ситуацию в конкретный момент. Business Agility сейчас действует в отраслях, связанных с развитием технологий, и в высококонкурентных сферах. Традиционные отраслевые границы размываются, яркий пример — банковская сфера, где банки начинают конкурировать с мобильными операторами и социальными сетями, которые не отягощены регулированием и отраслевыми традициями, благодаря чему действуют очень гибко. Соцсети и мобильные операторы предоставляют возможность перевода средств, отбирая банковскую комиссию, но и сами банки идут в смежные отрасли — продавая билеты, туры, страховки. К примеру, мобильный оператор МТС сейчас предоставляет банковские сервисы, включая кредитование, перевод денег и выпуск карт. Глобальные интернет-магазины, такие как Amazon и AliExpress, дают возможность переводить деньги и покупать в кредит или в рассрочку. «Яндекс» уже давно создал сервис электронных денег, а «Живой Журнал» создал жетоны, похожие на конвертируемую валюту.

Традиционный менеджмент довольно ограничен в организации деятельности: он подразумевает такие варианты, как Process management, Project management и Case management. Результат достигается только в случае Process management, да и там организация самого процесса не является технологично описанной деятельностью, а опирается на компетентность организатора. В случае Project management на компетентность участников также опираются фазы анализа и создания самого проекта, а для Case management требуется высокая компетентность во всей деятельности. Традиционный менеджмент в индустриальном обществе складывался медленно: к примеру, Форд делал свой конвейер около 10 лет. Интересно, что распространялся опыт на другие предприятия еще около 15-20 лет, несмотря на то, что Форд не делал секрета из своего способа организации производства, он даже проводил экскурсии для желающих.

Питер Друкер в книге «Менеджмент. Вызовы XXI века» сформулировал, что по мере автоматизации рутинного труда и переходу к операциям, связанным со знаниями, все большая доля деятельности будет требовать от сотрудников решений «менеджерского» уровня, которые в рамках традиционного менеджмента требуют личных способностей и опыта, и потому доступны ограниченному кругу сотрудников, получивших образование и прошедших отсев. Таковым будет общество, управляемое знаниями. То есть, области высокой компетентности станут расширяться и охватывать всю деятельность. В настоящее время сила этого вызова стремительно нарастает в связи с цифровизацией бизнеса. В банковской сфере стремительно переходят в цифровой вид, где людям остается только творческий труд, управление и обработка исключений. Казалось бы, в банки цифровизация пришла давно и все рутинные операции делают автоматизированные системы. Однако практически в них реализованы лишь типовые, устоявшиеся продукты, в то время как рынок не стоит на месте и надо искать конкурентное преимущество в предложении все новых продуктов или в переходе к индивидуализированному обслуживанию вместо массового. Разработка новых продуктов и качественное индивидуализированное обслуживание не может быть обеспечено регламентами, а требует творческой работы людей — что неизбежно потребует изменять организацию труда.

Еще один важный аспект — возникновение нового mindset, то есть новой конструкции мышления, которую принесли соцсети. Исследования шаблонов поведения и достижений лидерства в группах в Facebook показали, что способы достижения успеха противоречат традиционным шаблонам успешного поведения, закрепляемым корпоративной культурой. Раньше школы и вузы готовили человека к принятию правил. Выделялись дети, успешно воспринимавшие эту культуру, те же, кто демонстрировал альтернативные способы поведения, квалифицировались как хулиганы. Соцсети показывают, что можно достигать успеха и противоположными способами. Решить вопрос традиционным способом, к примеру, высоким уровнем зарплат, не получится. К примеру, Сбертеху еще 5 лет назад не удалось привлечь квалифицированных разработчиков, несмотря на предложение зарплат гораздо выше рынка: столкнувшись с принятыми там бюрократическими процедурами ведения проектов, они просто отказывались от предложений. Microsoft и IBM также столкнулись с этой проблемой и были вынуждены работать над изменением своей системы управления, переходя на Agile-подходы. IBM пошел на это после того, как лучшие выпускники университетов перестали принимать его предложения из-за корпоративного духа, предпочитая свободу стартапов. Инициативная молодежь вносит принципиальные изменения, иначе организации получат безынициативных сотрудников и специалистов старшего поколения, которых некем заменить.

Слайд из выступления на IT Spring, статья была без картинки

Все эти вызовы можно сформулировать как один: старые способы менеджмента через регламенты и организацию бизнес-процессов перестали работать. Чтобы найти ответ, надо понять, что именно сломалось в каждом конкретном бизнесе. Вызов — это не только опасность, это прежде всего возможность придумать ответ и стать первым, стать лидером. Каждая организация, каждый банк сам выбирает свою траекторию, делает ставки на те или иные способы преодоления. Однако чтобы представить себе спектр современных вызовов, а главное, работающие способы решения, которые возникли в разных отраслях, лучше обратиться к профессионалам — экспертам. Это похоже на строительство дома, который вовсе не нужно полностью строить самостоятельно: вы — заказчик, и дом должен быть удобен именно вам, архитекторы и дизайнеры помогут сориентироваться в стилях и современных материалах, помогут создать уникальную концепцию, которую затем будут воплощать специалисты других специальностей.

Роли в проекте: как поделить поляну ответственности (ТочкаСборки-2017)

2017-09-14T07:38:21Z

MaksTsepkov:

Точка Сборки в Санкт-Петербурге 09.09.2017
Повторен на РИФ Технологии в Ульяновске 30.09.2017
К сожалению, видео с Точки Сборки не получилось по техническим причинам.

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

В докладе я покажу разные варианты распределения ролей и ответственности в команде в зависимости от исходных условий и личностных особенностей участников проекта. Доклад является развитием и переосмыслением одноименного доклада на HappyDev в 2013 с учетом большого количества последующих докладов об разделении ответственности.

Что могут практики Agile и холакратии и нужны ли они Вашей организации (ПиР-2017)

2017-09-05T08:09:40Z

MaksTsepkov:

Выступление 05.09 на фестивале Практики и Развитие (ПиР) 2017
Видео выступления.

Agile, бирюзовые организации, холакратия… Многим кажется, что это – очередные модные buzzword, за которыми скрываются громкие обещания серебряной пули и ничего больше.

За этими словами лежат реальные инструменты – методы и практики, способные решать проблемы бизнеса. Как и любые инструменты, они эффективны в решении определенных проблем в конкретных ситуациях бизнеса, имеют свои преимущества и недостатки по сравнению с другими.

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

Agile – набор, доказавший свою эффективность в IT для решения подобных проблем, и переносимый сейчас в другие отрасли. Холакратия так же родилась в IT, как ответ на современные вызовы создания самоуправляемых организаций, движущихся к единой цели в динамичном мире, и обеспечивающих самореализацию сотрудников. Практики бирюзовых организаций достигают тех же целей.

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

Будущее уже наступило: от Agile к Бирюзовым организациям (Дни PR и маркетинга на Юге 2017)

2017-06-01T08:57:28Z

MaksTsepkov:

На конференции Дни PR и маркетинга на Юге 01.07.2017 в Ростове-на-Дону выступал с докладом «Будущее уже наступило: от Agile к Бирюзовым организациям», в котором для широкой аудитории незнакомых с Agile рассказал логику его становления и возможности использования в разных организациях. А вторая часть доклада была посвящена Спиральной динамике и бирюзовых организаций, которые описывают закономерности развития организаций в целом. И в этой логике Agile - это пионер из IT-отрасли, которая столкнулась с вызовами нового мира раньше других отраслей.

Доклад является развитием и расширением моего выступления Agile - ответ на вызовы третьей промышленной революции (AgileDays-2017 и ITSpring-2017), в котором существенно раскрыто содержание Agile - предыдущие доклады были на IT-конференциях, участникам которых содержание Agile известно.

Справа - скрайбинг моего выступления Алексея Гладкова-Евтушенко, а далее - презентация.

Видеозаписи на конференции не велось, однако доступно видео сокращенной версии доклада, которую я рассказывал на IT Spring Agile - ответ на вызовы третьей промышленной революции, однако, я не раскрываю там содержание Scrum, потому что выступал перед IT-аудиторией.

Для истории: мой пост на FB, фото выступления на FB [1] [2], [3]

Самоопределяйся технологично! (Максим Цепков на SQAdays-21 2017-05 в Москве)

2017-05-26T12:04:58Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про самоопределение}}

Еще про самоопределение

Доклад на SQAdays-21 25-26.05.2017 в Москве
Презентация на Slideshare
Видео https://vimeo.com/224282628 (в статье тоже есть)
Новая версия - Как строить свой профессиональный путь - схемы самоопределения (TeamLeadConf-2018)

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

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

Оригинал фото

Почему я решил выступить по этой теме и именно на конференции тестировщиков? Дело в том, что тестировщики за 2-3 года проходят начальную стадию набора опыта, а далее могут развиваться в очень большом количестве векторов — автоматизация, DevOps, менеджмент, usability, аналитики… И это для меня — не теоретическое знание, а опыт прошлых конференций, вопрос самоопределения стоит для очень многих участников. Поэтому я решил рассказать именно на этой конференции. А сама тема возникла для меня потому, что, с одной стороны, вопрос самоопределения для меня самого актуален, а с другой — из взаимодействия с сообществом СМД-методологов у меня появилась сборка схем по самоопределнию. А выступление — это такой способ проявления и закрепления практики, потому что в ходе подготовки кладешь на схеме не только свои кейсы, но и чужие. При этом конструкция — оригинальная, в публичных источниках ее нет, поэтому если для вас вопросы самоопределения актуальны — смотрите доклад. После доклада был BarCamp и обсуждения в кулуарах, и многие говорили, что схемы — полезны и навели на размышления.

IT-проект как связанные акты деятельности

2017-05-12T08:12:09Z

MaksTsepkov: Новая страница: «Для освоения инструментария СМД-схем я попробовал представить IT-проект в терминах схем…»

Для освоения инструментария СМД-схем я попробовал представить IT-проект в терминах схем акта деятельности. Получилось следующее:

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

Диаграммы учета как средство для наглядного и целостного отображения правил учета (Соколовские чтения-2017)

2017-04-22T20:32:25Z

MaksTsepkov:

Международный экономический симпозиум - Соколовские чтения 23-25.04.2017 в Санкт-Петербурге
Презентация на slideshare

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

Современные графические нотации и языки описания бизнеса, такие как UML, появившиеся за стремительным развитием информационных технологий, обходят тему графического представления учета стороной.

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

В докладе рассматриваются следующие ключевые моменты:

информация, существенная для целостного представления элементов учета на диаграмме;
варианты направления стрелок для представления проводок между счетами различной активности;
использование диаграмм для разработки правил учетной политики по отражению операций в бухгалтерском учете;
использование диаграмм для разработки плана счетов управленческого учета, с выделением разницы между управленческим и бухгалтерским учетом;
использование ресурсной модели и плана счетов для незамкнутого управленческого учета — учета товарных потоков, cashflow, налогового учета;
соответствие между различными видами учета и его отражение на диаграммах.

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

Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017)

2017-04-21T10:05:10Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Как выбрать для проекта практики проектирования и работы с требованиями

Доклад прочитан на AnalystDays-2017 21.04.2017
Доклад на сайте конференции
Презентация на slideshare
Видео на vimeo

Методы проектирования и работы с требованиями должны обеспечивать эффективную коммуникацию между всеми членами команды и гибкую разработку софта с возможностью дальнейшей модернизации. Развитие IT накопило богатый набор разнообразных практик, позволяющих достичь этого в проектах разной сложности, масштаба и назначения: user story, use case, BDD, TDD, FDD, DDD, архитектурная работа в SAFе, включая и более традиционные подходы. Как всегда бывает с широким набором инструментов, возникает проблема выбора подходящего. Часто просто выбирают знакомый инструмент или пытаются провести сравнение на модельных задачах, но то, что хорошо для небольшой задачи, не всегда подойдет длинному проекту.

В докладе будет сделан обзор различных практик, решаемых благодаря им коммуникационных задач и предполагаемого разделения труда в команде. Также будут представлены способы поддержки развития и модернизации продукта на долгом жизненном цикле. Доклад является развитием моего поста инженерные практики Agile.

Сотрудничество с корпорациями: рецепты из практики (Максим Цепков на ProfsoUX-2017)

2017-04-15T14:51:52Z

MaksTsepkov: Массовая правка: добавление Категория:Управление проектами

Выступление 15.04.2017 на ProfsoUX в Санкт-Петербурге
Выступление на сайте конференции
Презентация на slideshare
Публикация на FB
Видео на сайте 0x1.tv (Стас Фомин) на Vimeo

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

Agile - ответ на вызовы третьей промышленной революции (Максим Цепков на AgileDays-2017)

2017-03-22T08:06:00Z

MaksTsepkov:

Выступление 23.03 на AgileDays-2017, было развито 29.04 на IT Spring-2017
Доклад на сайте AgileDays
Презентация AgileDays на slideshare
Презентация IT Spring на slideshare
Видео с AgileDays на youtube
Видео с IT Spring на youtube

Кейсы бирюзовых организаций в России

2017-03-19T23:28:10Z

MaksTsepkov:

В этой статье собираю ссылки (первый список - 03.2017).

ВкусВилл - Избенка. Валерий Разгуляев на AgileBusiness Conference-2016 Видео https://youtu.be/KDN4xjI43xQ презентация https://www.slideshare.net/ScrumTrek/ss-68572441
Доктор на работе. Станислав Сажин на AgileDays-2016. Видео https://youtu.be/RSVub5m-3DM
Сбербанк - эксперимент в Балашихе, рассказ Влада Щукина с экскурсии https://www.facebook.com/groups/TealOrg/permalink/1840861809522994/
Райффайзенбанк. Холакратия, интервью Сергея Щетинина https://spiraldynamics.pro/evolyutsiya-rajffajzenbanka/
Кнопка экспериментирует https://habr.com/ru/company/knopka/blog/242491/ (2014)
Adventum — performance-агентство http://rb.ru/opinion/biryuza/ - интервью владельца, они там как пример по одному пункту
Pokupo — SaaS-решения для интернет-магазинов https://habrahabr.ru/company/zpayment/blog/313414/ - начало путь, но они маленькие, 15 человек
Дополнение по ПИР-2017 - Самарская компания Бизнес-гарант - рассказ «3D взгляд на бирюзовую трансформацию компании», генеральный директор Илья Руднев, HR-лиректор Вероника Стрелец, и их коуч-консультант Дмитрий Риман. Развернутых публичных материалов - не нашел.
Дополнение по Блог:Максима Цепкова/2017-11-24: Agile и бирюзовые организации - круглый стол в Открытой школе бизнеса - очень интересны кейсы движений Центр прикладной урбанистики и Живые города
Дополнение MindBox - открытые зарплаты, самоуправление, ориентация на построение бирюзовой компании. Интервью Александра Горника, Про бирюзовые продажи, Пост Игоря Новосельцева - впечатления с дня открытых дверей
Дополнение 2019 по ПИР-2019. Дмитрий Зацепин OIL Energy. Записей с ПИР нет (пока?), есть запись online-встречи с Дмитрием Зацепиным. В 2020 я ездил на экскурсию, в моем блоге есть отчеты день первый и день второй.
Дополнение: Банк Точка - внедрение холакратии с 2017 статья Дарьи Боровиковой и выступление Влады Бегановой - коучей по холакратии о работе. Где-то я слышал, что это - самое крупное внедрение в мире.

Часть ссылок - из поста https://habrahabr.ru/post/323532/, но проверено

От монолитных моделей предметной области - к модульным (Максим Цепков на WIAD-2017)

2017-02-18T10:29:53Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про DDD}}

Еще про DDD

Доклад прочитан 18.02 на World Information Architecture Day-2017 в Петербурге
Программа встречи 
Анонс выступления в блоге
Презентация на slideshare
Видео начало 09:25

Доклад про построение моделей предметной области. 20 лет назад делали большие монолитные ERP, но сейчас нет сомнений, что гибкий и быстро развиваемый софт должен быть модульным, а объекты – инкапсулировать сложность. Тот же путь проходят системы понятий и модели, описывающие предметную область, и Domain-Driven Design перенес наследование, полиморфизм, инкапсуляцию, плагины и другие подходы к разработке софта на работу с онтологиями и моделями предметной области.

Agile как сборка практик мышления

2017-02-09T06:34:04Z

MaksTsepkov: /* Выявление потребностей пользователей */

Проекты — для достижения результата, а не для освоения бюджета

2017-02-07T10:27:38Z

MaksTsepkov: Массовая правка: добавление Категория:Управление проектами

Статья была опубликована в журнале «Управление проектами» №1/2016 (пост в блоге). В чем разница между внешней и внутренней целью проекта? Почему важно предусмотреть фазу опытно-промышленной эксплуатации? Как правильно выстроить управление рисками и результативностью проекта?
В соответствии с условиями публикации, через полгода статья может быть размещена у меня на сайте - что я и делаю.

Казалось бы, заголовок статьи говорит про очевидную вещь, потому что именно ради достижения результатов осуществляют переход к проектному управлению от операционной деятельности. И отсутствие результатов можно однозначно трактовать просто как неумелое или некомпетентное ведение проекта. Однако на самом деле методология проектного управления содержит несколько подводных камней, пренебрежение которыми приводит к тому, что проект изначально оказывается ориентирован лишь на освоение бюджета, а если результат все же оказывается достигнут — то это заслуга конкретных руководителей, а не следования методологии. Именно этим особенностям проектного управления посвящена данная статья.

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

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

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

Здесь будет уместно привести следующий пример. При выводе на рынок нового продукта коммерческая компания предусматривает его продвижение и рекламу как часть проекта создания. Это позволяет не только организовать производство, но и обеспечить выполнение заложенных в проект показателей сбыта. Пока эти показатели не достигнуты, проект не может считаться завершенным. Конечно, продукт может получиться настолько замечательным, что отдельные мероприятия по продвижению не понадобятся, но изначальный отказ от них потребует явного обоснования при проектировании.

Надо отметить, что данная проблема проявляется в виде разрыва и на уровне методологии. Согласно PMI (Project Management Institute), эффективное использование результатов проекта не входит в состав самого проекта (Project Management), а относится к управлению программами проектов (Program Management). Такой разрыв на уровне методологии, безусловно, способствует проявлению этой проблемы в конкретных проектах. С другой стороны, методология включает в состав проекта изменения, которые должны привести к использованию результатов проекта в уже существующих операционных организациях и подразделениях или созданию новых. С этой точки зрения разрыва на методологическом уровне нет.

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

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

Естественно, на возможность достижения целевых показателей могут негативно повлиять изменения, произошедшие в ходе проекта. Эти изменения могут быть как внутренними (сроки проекта увеличиваются, а достигнутый результат оказывается меньше запланированного), так и внешними (например, увеличиваются цены на недвижимость). Это выводит нас к третьей проблемной области — управлению рисками и результативностью проекта. Эта составляющая часто трактуется упрощенно — как необходимость тщательного первоначального планирования и рассмотрения потенциальных угроз. Безусловно, планирование важно, но еще важнее постоянное наблюдение за изменениями в ходе проекта и прогноз результата с учетом этих изменений.

При начальном проектировании у команды обычно есть достаточно качественная модель проекта, которая позволяет отвечать на вопросы «что-если»: «А если на полгода позже?», «А если на 30% дешевле?» и тому подобные. Важно не потерять эту модель с переходом проекта в стадию реализации. Необходимо наладить регулярный мониторинг хода проекта и пересчет оценки результатов уже не по гипотетическому сценарию, а на основе реального хода проекта и изменений в экономике. Это позволит вовремя принять меры и произвести перепроектирование в случае выхода прогноза из диапазона устойчивости.

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

Тут стоит сказать несколько слов о популярной теме потенциально гибельных для проекта «черных лебедей», появление которых невозможно предусмотреть. На них могут списывать неудачи проектов: например, модернизированная электростанция, по мнению рабочей группы проекта, не смогла выйти на плановые поставки энергии потому, что крупная корпорация пересмотрела свои планы по открытию промышленного предприятия в регионе, чего нельзя было предположить изначально. Но если новое предприятие действительно предполагалось сделать ключевым потребителем энергии, следовало вступить в кооперацию еще на этапе проработки проекта электростанции и предложить соинвестирование с разделением рисков. В реальности планы открытия нового предприятия, скорее всего, приводились в проекте как подтверждение экономического роста региона и связанного с ним роста потребления энергии. А рост региона мог замедлиться по самым разным причинам, это можно отследить по ряду экономических показателей. В ходе проекта нужно постоянно наблюдать за теми показателями, на которые опирались при принятии решения о его старте; «черный лебедь» проявится в них так же, как и любые другие причины, и ситуация будет опознана в самом начале. Конечно, такой подход не объясняет, как реагировать, но он как минимум позволит принять меры непосредственно при возникновении ситуации, а не много позже, когда результат проекта окажется бесполезным.

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

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

Методически могут быть наложены ограничения на долю бюджета, до которой остановка считается нормальной. Например, в практике ведения государственных проектов в Великобритании существует ограничение бюджета начальных фаз проекта, после которых реализация должна быть уверенной. Ответственные за проект должны понимать, что остановка проекта на ранней фазе существенно лучше, чем реализация проекта, который окажется ненужным. Кроме того, гейты проекта — это естественные места для мониторинга хода движения и прогноза его завершения. Поэтому важно, чтобы проект был поделен на фазы с осязаемым результатом, завершение которых говорит о приближении к конечному результату, а не оценивался по доле освоенного бюджета. Если при этом прогноз выходит за пределы устойчивости проектов, то необходимо принимать меры. А вот отдельного решения в случае, если проект развивается успешно, требовать не нужно.

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

Smd-label

2017-01-29T20:07:39Z

MaksTsepkov: MaksTsepkov переименовал страницу Smd-label в MediaWiki:Smd-label без оставления перенаправления

СМД-методология

Smd-url

2017-01-29T20:07:02Z

MaksTsepkov: MaksTsepkov переименовал страницу Smd-url в MediaWiki:Smd-url без оставления перенаправления

Категория:СМД

Создать статьБудущее банков: искусственный интеллект, Agile и VIP-сервисы для всехю в данной категории

2016-12-23T16:40:30Z

MaksTsepkov: MaksTsepkov переименовал страницу Создать статьБудущее банков: искусственный интеллект, Agile и VIP-сервисы для всехю в данной категории в [[Буд…

На портале @ASTERA 14.11.2016 опубликована моя статья, посвященная тенденциям развития банковской отрасли. Почему банки начали активную экспансию в область нефинансовых услуг? Какие возможности дает банкам сервис управления финансами физлиц? Как изменились интерфейсы и модель обслуживания клиентов? Какие подходы необходимы банкам для внедрения новшеств? Об этом — в материале «Будущее банков: искусственный интеллект, Agile и VIP-сервисы для всех» на сайте издания, а здесь статья на сайте компании.

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