Сегодня расскажу про каналы своих подписчиков, как и обещал в посте про 5000. Каналы все классные!
Никита Харичкин ведёт канал Analyst Boost и сообщество по PlantUML. В канале — отчеты о конференциях, инсайты о работе аналитика и архитектора и полезные прихватки по работе с PlantUML. Вы, например, знали, что вместо activate/deactivate в диаграмме последовательности можно писать ++/--? Я вот тоже нет.
Дмитрий в канале DevFM пишет для Python разработчиков, но не только! Есть интересные посты про проведение ретро, про дизайн-документы от Google, про управление командой и коммуникации, а особенно мне понравились посты про всякие маааленькие нюансы: как лучше всего хранить в БД номера телефонов? Чем заменить cron, если нужно очень хитрое расписание? Какой тип данных выбрать для хранения строк — char, varchar или text? Обычные повседневные вопросы, которые оказываются не совсем простыми.
Канал "Пасека аналитика": жизнь и карьера аналитика, рефлексия опыта и безвозмездное менторство (!). Ловите момент.
Архитектура проектов на Unity. Хардкорный канал! Если вы думаете, Unity — это какая-то ерунда про игры, то вы больше так не думайте — Алексей пишет про программную инженерию в самом серьезном понимании. А посты про когнитивную сложность программ — просто моё почтение!
Ещё один хардкорный канал: Лабораторные информационные менеджмент-системы и аккредитацию лабораторий. Метрология, стандарты, валидация ПО, управление качеством. Серьезные дела. Пошел читать ГОСТ ISO 17025.
Канал Валентина Заботина "Аналитик маминой подруги" — про работу и карьеру в системном анализе, а главное — про денюжки, деньгушечки, откровенно и честно. Всегда интересно.
Вот такие у меня классные подписчики! Желаю всем нам роста и успехов! И не стесняйтесь писать о себе и о том, что вам интересно!
Никита Харичкин ведёт канал Analyst Boost и сообщество по PlantUML. В канале — отчеты о конференциях, инсайты о работе аналитика и архитектора и полезные прихватки по работе с PlantUML. Вы, например, знали, что вместо activate/deactivate в диаграмме последовательности можно писать ++/--? Я вот тоже нет.
Дмитрий в канале DevFM пишет для Python разработчиков, но не только! Есть интересные посты про проведение ретро, про дизайн-документы от Google, про управление командой и коммуникации, а особенно мне понравились посты про всякие маааленькие нюансы: как лучше всего хранить в БД номера телефонов? Чем заменить cron, если нужно очень хитрое расписание? Какой тип данных выбрать для хранения строк — char, varchar или text? Обычные повседневные вопросы, которые оказываются не совсем простыми.
Канал "Пасека аналитика": жизнь и карьера аналитика, рефлексия опыта и безвозмездное менторство (!). Ловите момент.
Архитектура проектов на Unity. Хардкорный канал! Если вы думаете, Unity — это какая-то ерунда про игры, то вы больше так не думайте — Алексей пишет про программную инженерию в самом серьезном понимании. А посты про когнитивную сложность программ — просто моё почтение!
Ещё один хардкорный канал: Лабораторные информационные менеджмент-системы и аккредитацию лабораторий. Метрология, стандарты, валидация ПО, управление качеством. Серьезные дела. Пошел читать ГОСТ ISO 17025.
Канал Валентина Заботина "Аналитик маминой подруги" — про работу и карьеру в системном анализе, а главное — про денюжки, деньгушечки, откровенно и честно. Всегда интересно.
Вот такие у меня классные подписчики! Желаю всем нам роста и успехов! И не стесняйтесь писать о себе и о том, что вам интересно!
🔥13❤6🥱3👍2🤡1
К вопросу, что мы делаем с требованиями. Я тут написал — "собираем", на что получил справедливое возражение, что нечего там собирать, нет их у стейкхолдеров, по крайне мере обоснованных и четко сформулированных. Не растут требования, как грибы — только возьми и собери.
Как сказать лучше? Выявляем? Ну, как будто они скрыты, а мы их делаем явными? Отчасти верно: когда мы исследуем предметный домен и структуру проблемы, мы выявляем объекты и действия, которые в них есть, но про которые специально не говорят, потому что не фокусируются на них. Ну а аналитики делают их явными, в этом смысле, наверное, выявляют. Про техники такого выявления я рассказывал и писал.
Ещё вариант: извлекаем. Это скорее про документы, где есть какие-то тексты про предметку и процессы, и в которых, при желании, требования можно увидеть.
Но, давайте будем честны: мы требования просто придумываем! Сами, или, если повезло — совместно со стейкхолдерами.
Можно этот процесс маскировать словом "разработка" требований (был и такой вариант). Или, чтобы совсем красиво звучало: co-development, или совсем по-модному co-design. И придумал это не Пол Ральф со своими статьями про контрпродуктивность идеи "сбора требований", а задолго до него.
Например, Клаус Пол (Klaus Pohl, один из основателей сертификации IREB) ещё в 2007 описал метод COSMOD-RE, где честно говорится: требования и архитектура системы разрабатываются в едином процессе co-development'а. И шаги "разработка целей и сценариев" и "разработка архитектуры" там на одном уровне (на самом деле это единый процесс).
Метод, по-видимому, плотно забыт, описания его еле гуглятся, а текстов статей и докладов нет в открытом доступе. Но можно посмотреть на несколько картинок.
COSMOD-RE задает 4 уровня:
1. Системы в целом;
2. Функциональной декомпозиции системы (разбивку на компоненты);
3. Распределение софтверных компонент по железу;
4. Уровень развертывания.
На каждом уровне происходит этот самый co-development требований и архитектуры, с уточнением деталей, а иногда и с возвратом на более высокий уровень и пересмотром принятых решений. Кажется, на русском про это говорят "прорабатываем требования и решения", или "разработка и анализ требований".
Любопытно (и полезно!), что здесь выделено 4 уровня, причем последние 2 захватывают хардвер. Аналитики же, даже системные, обычно в своих абстракциях далеки от размышлений — на чем всё это будет крутиться.
На курсе по проектированию интеграций часто вижу, как ломаются абстракции, когда мы начинаем говорить про Кафку, и выясняется, что это кластер и нужно думать про репликацию и вылет машин из кластера. Ну где, скажите, требования, а где кластеры. И хорошо, когда они объединены на одной картинке и в одном методе.
Как сказать лучше? Выявляем? Ну, как будто они скрыты, а мы их делаем явными? Отчасти верно: когда мы исследуем предметный домен и структуру проблемы, мы выявляем объекты и действия, которые в них есть, но про которые специально не говорят, потому что не фокусируются на них. Ну а аналитики делают их явными, в этом смысле, наверное, выявляют. Про техники такого выявления я рассказывал и писал.
Ещё вариант: извлекаем. Это скорее про документы, где есть какие-то тексты про предметку и процессы, и в которых, при желании, требования можно увидеть.
Но, давайте будем честны: мы требования просто придумываем! Сами, или, если повезло — совместно со стейкхолдерами.
Можно этот процесс маскировать словом "разработка" требований (был и такой вариант). Или, чтобы совсем красиво звучало: co-development, или совсем по-модному co-design. И придумал это не Пол Ральф со своими статьями про контрпродуктивность идеи "сбора требований", а задолго до него.
Например, Клаус Пол (Klaus Pohl, один из основателей сертификации IREB) ещё в 2007 описал метод COSMOD-RE, где честно говорится: требования и архитектура системы разрабатываются в едином процессе co-development'а. И шаги "разработка целей и сценариев" и "разработка архитектуры" там на одном уровне (на самом деле это единый процесс).
Метод, по-видимому, плотно забыт, описания его еле гуглятся, а текстов статей и докладов нет в открытом доступе. Но можно посмотреть на несколько картинок.
COSMOD-RE задает 4 уровня:
1. Системы в целом;
2. Функциональной декомпозиции системы (разбивку на компоненты);
3. Распределение софтверных компонент по железу;
4. Уровень развертывания.
На каждом уровне происходит этот самый co-development требований и архитектуры, с уточнением деталей, а иногда и с возвратом на более высокий уровень и пересмотром принятых решений. Кажется, на русском про это говорят "прорабатываем требования и решения", или "разработка и анализ требований".
Любопытно (и полезно!), что здесь выделено 4 уровня, причем последние 2 захватывают хардвер. Аналитики же, даже системные, обычно в своих абстракциях далеки от размышлений — на чем всё это будет крутиться.
На курсе по проектированию интеграций часто вижу, как ломаются абстракции, когда мы начинаем говорить про Кафку, и выясняется, что это кластер и нужно думать про репликацию и вылет машин из кластера. Ну где, скажите, требования, а где кластеры. И хорошо, когда они объединены на одной картинке и в одном методе.
❤12🔥12👍6
В английском всё это называется 'requirements elicitation', а оксфордский словарь говорит, что происхождение слова elicit — mid 17th century: from Latin elicit- ‘drawn out by trickery or magic’, “вытянутый обманом или магией". С этим определением я согласен 🧙♂
Почему не получается просто спросить про требования? В одной старой статье* приводится три категории проблем с требованиями:
⭐️ Проблема объема и границ:
— непонятно, где границы решения (где мы остановимся и чего не будем делать);
— лишние преждевременные детали (зависаем на них, не успеваем обсудить весь объем);
⭐️ Проблемы понимания:
— пользователи не до конца понимают, что им на самом деле нужно. Это они не специально, это проблема неосознаваемого знания (tacit knowledge);
— пользователи плохо понимают возможности и ограничения ИТ-систем (добавьте сюда привычку говорить не о проблемах, а сразу о решениях — и вы получите дилетантское мнение, если вовремя не вернете инициативу);
— аналитики и разработчики, в свою очередь, плохо разбираются в домене;
— аналитики и пользователи говорят на разных языках;
— "очевидная" информация пропускается, причём с обеих сторон;
— разные стейкхолдеры выдвигвают противоречащие требования;
— формулировки "требований" нечеткие и непроверяемые;
⭐️ Проблема изменения "требований":
— возможно, изменилась внешние условия и, соответственно, потребности;
— но, скорее всего, понимание возможностей системы и своих нужд растёт — то есть, вопрос в расширении знаний и осознанности. Сразу требовать полной осознанности от пользователя — слишком круто.
Приходится либо ждать, пока он дозреет, либо использовать обман и магию.
* Technical Report CMU/SEI-92-TR-012 ESC-TR-92-012, Issues in Requirements Elicitation, Michael G. Christel, Kyo C. Kang, 1992
Почему не получается просто спросить про требования? В одной старой статье* приводится три категории проблем с требованиями:
— непонятно, где границы решения (где мы остановимся и чего не будем делать);
— лишние преждевременные детали (зависаем на них, не успеваем обсудить весь объем);
— пользователи не до конца понимают, что им на самом деле нужно. Это они не специально, это проблема неосознаваемого знания (tacit knowledge);
— пользователи плохо понимают возможности и ограничения ИТ-систем (добавьте сюда привычку говорить не о проблемах, а сразу о решениях — и вы получите дилетантское мнение, если вовремя не вернете инициативу);
— аналитики и разработчики, в свою очередь, плохо разбираются в домене;
— аналитики и пользователи говорят на разных языках;
— "очевидная" информация пропускается, причём с обеих сторон;
— разные стейкхолдеры выдвигвают противоречащие требования;
— формулировки "требований" нечеткие и непроверяемые;
— возможно, изменилась внешние условия и, соответственно, потребности;
— но, скорее всего, понимание возможностей системы и своих нужд растёт — то есть, вопрос в расширении знаний и осознанности. Сразу требовать полной осознанности от пользователя — слишком круто.
Приходится либо ждать, пока он дозреет, либо использовать обман и магию.
* Technical Report CMU/SEI-92-TR-012 ESC-TR-92-012, Issues in Requirements Elicitation, Michael G. Christel, Kyo C. Kang, 1992
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍3🔥3😁1
Майк Кон — сооснователь Scrum Alliance и эксперт в пользовательских историях — выделяет три категории требований:
➕ Известные (которые удалось "выявить", "собрать" или "разработать");
➕ Пропущенные (которые мы могли бы в принципе собрать, но как-то не получилось — мы не спросили, а пользователи про них не сказали);
➕ Эмерджентные — которые нельзя было предугадать заранее. Про них не знал ни аналитик, ни сам стейкхолдер — он понял, что ему это нужно, только когда увидел/начал пользоваться системой.
Ещё раз: это не то, что мы проглядели, это то, что мы в принципе не могли предугадать.
Это принципиальная разница между plan-driven и agile подходами, или даже взглядом на мир. В первом случае мы верим в рациональность, силу разума и познаваемость мира через точно построенные умозрительные схемы. То есть, в конечном счете, — в совершенство мира.
Во втором — верим, что мир в целом несовершенен, поведение людей иррационально, знания неполны, а модели дырявы. Но при этом мы не отказываемся от действий в этом несовершенном мире.
Вопрос подхода — это вопрос мировозрения, оптимизма и честного взгляда на обстоятельства. И, судя по тому, как каждый раз удивляются адепты рационалистского взгляда — в случае требований стоит признать, что есть требования, о которых никто не может подумать, пока не увидит работающую систему или хотя бы её прототип.
Самое интересное, добавляет Кон, — что эмерджентные требования могут оказаться как раз самыми нужными.
Отсюда идея — показывать хотя бы что-то, что может вызвать генерацию идей у пользователей. Поэтому первая версия интерфейсов — это не итоговый проект, это стимульный материал для выявления дополнительных требований, для запуска фантазии. И в плане нужно всегда отводить место на эти новые требования.
Ещё раз: это не то, что мы проглядели, это то, что мы в принципе не могли предугадать.
Это принципиальная разница между plan-driven и agile подходами, или даже взглядом на мир. В первом случае мы верим в рациональность, силу разума и познаваемость мира через точно построенные умозрительные схемы. То есть, в конечном счете, — в совершенство мира.
Во втором — верим, что мир в целом несовершенен, поведение людей иррационально, знания неполны, а модели дырявы. Но при этом мы не отказываемся от действий в этом несовершенном мире.
Вопрос подхода — это вопрос мировозрения, оптимизма и честного взгляда на обстоятельства. И, судя по тому, как каждый раз удивляются адепты рационалистского взгляда — в случае требований стоит признать, что есть требования, о которых никто не может подумать, пока не увидит работающую систему или хотя бы её прототип.
Самое интересное, добавляет Кон, — что эмерджентные требования могут оказаться как раз самыми нужными.
Отсюда идея — показывать хотя бы что-то, что может вызвать генерацию идей у пользователей. Поэтому первая версия интерфейсов — это не итоговый проект, это стимульный материал для выявления дополнительных требований, для запуска фантазии. И в плане нужно всегда отводить место на эти новые требования.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32👍11❤1
Ещё одна идея от Майка Кона, которой у других не встречал: приоритизация задач по тому, что нового мы можем узнать, чему научиться.
Точнее, по трём параметрам:
1. Востребованность пользователями, это понятно.
2. Что нового мы сможем узнать? Это могут быть знания о поведении и предпочтениях пользователей или что-то о новой технологии.
3. Какой риск может быть снижен или устранен в результате реализации этой функции? Если мы видим риски, то лучше встретиться с ними как можно раньше.
И в бэклог спринта лучше всего брать задачи, продвигающие команду и заказчиков по всем трем признакам.
Точнее, по трём параметрам:
1. Востребованность пользователями, это понятно.
2. Что нового мы сможем узнать? Это могут быть знания о поведении и предпочтениях пользователей или что-то о новой технологии.
3. Какой риск может быть снижен или устранен в результате реализации этой функции? Если мы видим риски, то лучше встретиться с ними как можно раньше.
И в бэклог спринта лучше всего брать задачи, продвигающие команду и заказчиков по всем трем признакам.
🔥8👍1🤔1
Взгляд на работу с требованиями с точки зрения дисциплины управления знаниями (knowledge managemant, KM) оказался очень любопытным, и объясняющим некоторые вещи. Я-то, так вышло, работал с методами KM, и даже был когда-то членом экспертного совета премии Most Admired Knowledge Enterprise Russia, так что с темой знаком. А вот для аналитиков и архитекторов, на удивление, эта тема малоизвестна. Хотя разговор про архитектуру систем всегда затрагивает вопросы управления знаниями, это у меня один из главный инсайтов с курса про микросервисную архитектуру. Закон Конвея и разделение по командам тоже про управление знаниями — какие знания аккумулировать в команде, а какие выдавать наружу.
С точки зрения системного анализа, KM тоже много где проявляется: это и сбор знаний со стейкхолдеров (специально не пишу "требований", потому что правильнее — знаний о предметной области и проблемах, которые мы собираемся решить), и передача знаний в команду (очень часто аналитика называют "единым источником информации о системе", "координатором знаний о системе", а при этом управлению знаниями-то и не учат!).
Например, такая вещь, как модель SECI (или модель Nonaka-Takeuchi) объясняет, что для разных стадий работы со знаниями нужные разные методы. Модель вводит различение между неявными знаниями (tacit knowledge, существует только в головах или в навыках людей и часто даже не осознается) и явными, эксплицитными (explicit knowledge, существует в виде отчужденного артефакта: документа, описания, регламента, записей). Если бы все знания были эксплицитными, и задачи разработки требований бы не было, точнее, она была бы сугубо технической.
Модель SECI постулирует, что любое знание сначала возникает, как неявное, и передается через социальные взаимодействия: наблюдение, имитацию, практику под руководством. Такая передача знаний требует прямого взаимодействия. Формирующееся в результате знание тоже неявное. Это как раз и происходит в малых командах, отсюда и сопротивление ведению документации.
Потому что документация — это эксплицитное знание, и переход требует значительных усилий — экстернализации. Это то, чем часто занимается аналитик — экстернализирует неявные знания.
Экстернализированные знания становятся операбельными — с ними можно что-то сделать. Их проще передать от человека к человеку (хоть и с потерями). Их можно анализировать, из можно сочетать и комбинировать друг с другом, вырабатывать новые эксплицитные знания — в частности, из формального описания предметной области и проблемы выводить формальные требования к решению. Крайняя степень формализации знаний — это и есть программный код. Это зафиксированные и готовые к использованию знания, максимально оторванные от конкретного человека.
И вот тут возникает интересная вещь — круг замыкается, и происходит интернализация, переход от эксплицитных знаний к неявным. Готовая система становится элементом среды, в которой действуют люди, и способ, которым они решают свои задачи при помощи системы, нигде не зафиксирован. И на следующем витке вновь возникает задача извлечения, экстернализации знаний о реальной практике использования системы. Процесс входит в цикл.
(Картинка из статьи Germán Scalzo и Guillermo Fariñas, лицензия CC BY 4.0)
С точки зрения системного анализа, KM тоже много где проявляется: это и сбор знаний со стейкхолдеров (специально не пишу "требований", потому что правильнее — знаний о предметной области и проблемах, которые мы собираемся решить), и передача знаний в команду (очень часто аналитика называют "единым источником информации о системе", "координатором знаний о системе", а при этом управлению знаниями-то и не учат!).
Например, такая вещь, как модель SECI (или модель Nonaka-Takeuchi) объясняет, что для разных стадий работы со знаниями нужные разные методы. Модель вводит различение между неявными знаниями (tacit knowledge, существует только в головах или в навыках людей и часто даже не осознается) и явными, эксплицитными (explicit knowledge, существует в виде отчужденного артефакта: документа, описания, регламента, записей). Если бы все знания были эксплицитными, и задачи разработки требований бы не было, точнее, она была бы сугубо технической.
Модель SECI постулирует, что любое знание сначала возникает, как неявное, и передается через социальные взаимодействия: наблюдение, имитацию, практику под руководством. Такая передача знаний требует прямого взаимодействия. Формирующееся в результате знание тоже неявное. Это как раз и происходит в малых командах, отсюда и сопротивление ведению документации.
Потому что документация — это эксплицитное знание, и переход требует значительных усилий — экстернализации. Это то, чем часто занимается аналитик — экстернализирует неявные знания.
Экстернализированные знания становятся операбельными — с ними можно что-то сделать. Их проще передать от человека к человеку (хоть и с потерями). Их можно анализировать, из можно сочетать и комбинировать друг с другом, вырабатывать новые эксплицитные знания — в частности, из формального описания предметной области и проблемы выводить формальные требования к решению. Крайняя степень формализации знаний — это и есть программный код. Это зафиксированные и готовые к использованию знания, максимально оторванные от конкретного человека.
И вот тут возникает интересная вещь — круг замыкается, и происходит интернализация, переход от эксплицитных знаний к неявным. Готовая система становится элементом среды, в которой действуют люди, и способ, которым они решают свои задачи при помощи системы, нигде не зафиксирован. И на следующем витке вновь возникает задача извлечения, экстернализации знаний о реальной практике использования системы. Процесс входит в цикл.
(Картинка из статьи Germán Scalzo и Guillermo Fariñas, лицензия CC BY 4.0)
🔥25❤5👍4
Какая-то неделя рекомендаций каналов у меня получается. Вот тут ребята собрали папку каналов про agile, стратегию и системный анализ. Назвали, правда, «Гибкие технологии управления», но темы там шире. Всё про варианты развития аналитика: можно идти в организаторы процессов (читай — agile), можно в продакты или бизнес-партнеры, а там неизбежно придётся столкнуться со разработкой стратегии.
На большинство из них я сам подписан и читаю, так что могу уверенно рекомендовать.
Добавляйте папку, читайте каналы, набирайтесь новых идей!
https://news.1rj.ru/str/addlist/pB26PWfXrAFkMWYy
На большинство из них я сам подписан и читаю, так что могу уверенно рекомендовать.
Добавляйте папку, читайте каналы, набирайтесь новых идей!
https://news.1rj.ru/str/addlist/pB26PWfXrAFkMWYy
Telegram
Agile 🇷🇺
Ирина invites you to add the folder “Agile 🇷🇺”, which includes 12 chats.
👍3💩3🤮2🫡2👎1
В продолжение разговора о явных и неявных знаниях.
Понятно, что неявное знание гораздо проще и приятнее передавать тоже как неявное, а не экстернализировать, что требует значимых усилий. А иногда и сопротивления.
И методы для изучения этих знаний должны быть соответствующие: демонстрация, наблюдение — пусть покажут и объяснят, как они это делают.
Может быть даже — выполнение с помощью эксперта. Вы сами попробуйте сделать, а пользователь пусть вам рассказывает — на что когда обратить внимание. Способ, кстати, очень мощный, особенно для проектирования интерфейсов — сразу позволяет многое узнать о контексте и о том, что важно. Сложно представить ситуацию курьера на велосипеде с мобильным приложением, или водителя, или учителя во время урока, пока сам в эту ситуацию не окунешся. Из удобного кресла в тихом кабинете такое не представишь.
Нужно сходить на гэмба — место производства, как это в японском менеджменте называется. Там достоверные знания.
Если так не получается — хотя бы попросите пользователя в деталях рассказать о ситуации, в которой планируется использовать ваш продукт. Причем, с контекстом: где он, как сидит/стоит/бежит, есть ли кто-то рядом (кто должен или не должен видеть информацию), есть ли давление времени (какой-то фактор, который требует выполнить операцию быстрее), ещё какие-то отвлекающие или давящие факторы. И пусть не фантазирует, а описывает реально случившуюся ситуацию!
А показывать человеку описания, схемы и модели в этом случае почти бесполезно — знания-то неявные, они в такой форме никогда не существовали и непонятно, как к ним относиться. Особенно если ты не участвовал в их создании и не очень понимаешь концепции модели. Помню, в одной далекой южной стране показал я таксистам карту — вот они удивились! Из рук в руки передавали, пытались понять, что за штука такая. Это что, как будто наш город с высоты? Ух ты. И такое бывает. А зачем? Чего только эти туристы не придумают.
Понять, что знания неявные, очень просто: они не зафиксированы. Нет ни схем, ни регламентов, ни чеклистов, ничего. Как выполнять работу — передается из уст в уста, уровень зрелости процессов — 2, "фольклор" (первый уровень — "анархия", когда повторяемой деятельности вообще нет, нет процессов).
И тут аналитик становится фольклористом. И только собрав достаточно материала может систематизировать его и выявитьморфологию волшебной сказки структуру деятельности в предметной области.
Понятно, что неявное знание гораздо проще и приятнее передавать тоже как неявное, а не экстернализировать, что требует значимых усилий. А иногда и сопротивления.
И методы для изучения этих знаний должны быть соответствующие: демонстрация, наблюдение — пусть покажут и объяснят, как они это делают.
Может быть даже — выполнение с помощью эксперта. Вы сами попробуйте сделать, а пользователь пусть вам рассказывает — на что когда обратить внимание. Способ, кстати, очень мощный, особенно для проектирования интерфейсов — сразу позволяет многое узнать о контексте и о том, что важно. Сложно представить ситуацию курьера на велосипеде с мобильным приложением, или водителя, или учителя во время урока, пока сам в эту ситуацию не окунешся. Из удобного кресла в тихом кабинете такое не представишь.
Нужно сходить на гэмба — место производства, как это в японском менеджменте называется. Там достоверные знания.
Если так не получается — хотя бы попросите пользователя в деталях рассказать о ситуации, в которой планируется использовать ваш продукт. Причем, с контекстом: где он, как сидит/стоит/бежит, есть ли кто-то рядом (кто должен или не должен видеть информацию), есть ли давление времени (какой-то фактор, который требует выполнить операцию быстрее), ещё какие-то отвлекающие или давящие факторы. И пусть не фантазирует, а описывает реально случившуюся ситуацию!
А показывать человеку описания, схемы и модели в этом случае почти бесполезно — знания-то неявные, они в такой форме никогда не существовали и непонятно, как к ним относиться. Особенно если ты не участвовал в их создании и не очень понимаешь концепции модели. Помню, в одной далекой южной стране показал я таксистам карту — вот они удивились! Из рук в руки передавали, пытались понять, что за штука такая. Это что, как будто наш город с высоты? Ух ты. И такое бывает. А зачем? Чего только эти туристы не придумают.
Понять, что знания неявные, очень просто: они не зафиксированы. Нет ни схем, ни регламентов, ни чеклистов, ничего. Как выполнять работу — передается из уст в уста, уровень зрелости процессов — 2, "фольклор" (первый уровень — "анархия", когда повторяемой деятельности вообще нет, нет процессов).
И тут аналитик становится фольклористом. И только собрав достаточно материала может систематизировать его и выявить
🔥15👍5❤4🤯1
Всем привет! В канале большое пополнение, поэтому давайте я напишу о себе. Может быть, будет интересно и тем, кто читает меня давно.
Меня зовут Юрий Куприянов. Я занимаюсь созданием ИТ-систем с 1998 года. Первые лет 10 работал программистом, тимлидом, архитектором систем. Где-то это был фриланс, где-то я работал в штате, занимался разработкой в разных областях: в медицине (одна из первых систем цифрового анализа ЭКГ), в нефтянке (писал софт для управления Ванинским НПЗ), в туризме (термина TravelTech тогда ещё не было), недвижке, hrTech, и т.д. Чуть было не написал одну из первых CMS, но один умный товарищ сказал — ну что ты ерундой занимаешься, какие-то там сайтики, иди нормальные вещи пиши на C++! До сих пор жалею.
Так получилось, что на всех проектах я выполнял роль аналитика, а зачастую и продакта — собирал требования, проводил обследования, писал ТЗ, когда было нужно, проектировал интерфейсы, пытался понять — что нужно пользователям. Вообще тогда не было такого сильного разделения труда — например, мы не знали о роли DevOps, а просто брали и выстраивали пайплайн релизов и миграций, анализировали нагрузку и администрировали сервера. Когда возникала задача поговорить с пользователями и выяснить, что им нужно, как-то так получалось, что шёл к ним разговаривать я. А если так не получалось, и шёл не я — на проекте начиналась твориться лютая дичь: например, мы только к концу разработки узнали, что система по подбору объектов недвижимости должна, оказывается, работать в киоске с тач-интерфейсом, а не на десктопе с мышкой.
Самым мощным проектом из тех времен было создание системы Казначейства Газпромбанка; она, кажется, работает уже 20 лет, хотя, конечно, морально и архитектурно ужасно устарела. Её вроде бы уже несколько лет переписывают много людей, не знаю, что там сейчас. Я был из тех самых 10x-еров, которые заменяют сразу 10 человек: мы написали всю систему буквально вдвоём + два стажера (они оба уже давно CTO крупных банков). Именно тогда я стал заниматься образованием и выпустил много отличных ребят — почти все сейчас либо основатели своих компаний (например, Флант), либо технические, либо дизайн-директора.
Потом я стал заниматься координацией работ в больших проектах, задачами анализа и проектирования корпоративной архитектуры. Возглавлял управление методологии, архитектуры и документации в Национальном расчетном депозитарии. Потом плюнул на корпоративный мир и занялся интернет-стартапом про онлайн-трансляции и видео-созвоны, когда про это ещё мало кто слышал (Zoom вышел в год нашего закрытия). Было весело: мы транслировали чемпионат России по спортивной гимнастике, первые интенсивы Бизнес-Молодости и концерты Московской Консерватории. Как обычно, всё сдохло из-за отсутствия маркетинга и присутствия флеша. Потом я занимался управлением знаниями, спроектировал систему управления идеями для Сбера, был экспертом премии MAKE Russia (Most Admired Knowledge Enterprise).
Параллельно я продолжал преподавать в МИЭМ, МФТИ, НИУ ВШЭ, в каком-то году был даже лучшим преподом Вышки по выбору студентов, и в 2015 эти интересы сошлись — я поучаствовал в запуске платформы "Открытое образование" — сначала написал начальное ТЗ, а потом руководил разработкой в роли директора по продуктам. Директор по продуктам я, правда специфический: больше про упихивание в срок невозможных проектов (openedu.ru запустили за 6 месяцев — от состояния "есть ТЗ и один Юра", до состояния "сплоченная команда внутренней разработки, три команды подрядчиков, курсы загружены на платформу, студенты начали регистрироваться") и про удовлетворенность пользователей (тот же openedu набрал полтора миллиона пользователей без маркетинга вообще). Так вышло, что с чисто коммерческими продуктами я мало работал. Хотя какое-то время дрючил разные проекты в заочке ФРИИ.
В общем, уже почти 10 лет я занимаюсь созданием систем в EdTech: Coreapp.ai, Университет 2035, в последний раз делал попытку привести в чувство Московскую электронную школу, но не очень преуспел в этом тяжком деле. Выгорел, собрал все шишки, временно ушёл "на пенсию".
Меня зовут Юрий Куприянов. Я занимаюсь созданием ИТ-систем с 1998 года. Первые лет 10 работал программистом, тимлидом, архитектором систем. Где-то это был фриланс, где-то я работал в штате, занимался разработкой в разных областях: в медицине (одна из первых систем цифрового анализа ЭКГ), в нефтянке (писал софт для управления Ванинским НПЗ), в туризме (термина TravelTech тогда ещё не было), недвижке, hrTech, и т.д. Чуть было не написал одну из первых CMS, но один умный товарищ сказал — ну что ты ерундой занимаешься, какие-то там сайтики, иди нормальные вещи пиши на C++! До сих пор жалею.
Так получилось, что на всех проектах я выполнял роль аналитика, а зачастую и продакта — собирал требования, проводил обследования, писал ТЗ, когда было нужно, проектировал интерфейсы, пытался понять — что нужно пользователям. Вообще тогда не было такого сильного разделения труда — например, мы не знали о роли DevOps, а просто брали и выстраивали пайплайн релизов и миграций, анализировали нагрузку и администрировали сервера. Когда возникала задача поговорить с пользователями и выяснить, что им нужно, как-то так получалось, что шёл к ним разговаривать я. А если так не получалось, и шёл не я — на проекте начиналась твориться лютая дичь: например, мы только к концу разработки узнали, что система по подбору объектов недвижимости должна, оказывается, работать в киоске с тач-интерфейсом, а не на десктопе с мышкой.
Самым мощным проектом из тех времен было создание системы Казначейства Газпромбанка; она, кажется, работает уже 20 лет, хотя, конечно, морально и архитектурно ужасно устарела. Её вроде бы уже несколько лет переписывают много людей, не знаю, что там сейчас. Я был из тех самых 10x-еров, которые заменяют сразу 10 человек: мы написали всю систему буквально вдвоём + два стажера (они оба уже давно CTO крупных банков). Именно тогда я стал заниматься образованием и выпустил много отличных ребят — почти все сейчас либо основатели своих компаний (например, Флант), либо технические, либо дизайн-директора.
Потом я стал заниматься координацией работ в больших проектах, задачами анализа и проектирования корпоративной архитектуры. Возглавлял управление методологии, архитектуры и документации в Национальном расчетном депозитарии. Потом плюнул на корпоративный мир и занялся интернет-стартапом про онлайн-трансляции и видео-созвоны, когда про это ещё мало кто слышал (Zoom вышел в год нашего закрытия). Было весело: мы транслировали чемпионат России по спортивной гимнастике, первые интенсивы Бизнес-Молодости и концерты Московской Консерватории. Как обычно, всё сдохло из-за отсутствия маркетинга и присутствия флеша. Потом я занимался управлением знаниями, спроектировал систему управления идеями для Сбера, был экспертом премии MAKE Russia (Most Admired Knowledge Enterprise).
Параллельно я продолжал преподавать в МИЭМ, МФТИ, НИУ ВШЭ, в каком-то году был даже лучшим преподом Вышки по выбору студентов, и в 2015 эти интересы сошлись — я поучаствовал в запуске платформы "Открытое образование" — сначала написал начальное ТЗ, а потом руководил разработкой в роли директора по продуктам. Директор по продуктам я, правда специфический: больше про упихивание в срок невозможных проектов (openedu.ru запустили за 6 месяцев — от состояния "есть ТЗ и один Юра", до состояния "сплоченная команда внутренней разработки, три команды подрядчиков, курсы загружены на платформу, студенты начали регистрироваться") и про удовлетворенность пользователей (тот же openedu набрал полтора миллиона пользователей без маркетинга вообще). Так вышло, что с чисто коммерческими продуктами я мало работал. Хотя какое-то время дрючил разные проекты в заочке ФРИИ.
В общем, уже почти 10 лет я занимаюсь созданием систем в EdTech: Coreapp.ai, Университет 2035, в последний раз делал попытку привести в чувство Московскую электронную школу, но не очень преуспел в этом тяжком деле. Выгорел, собрал все шишки, временно ушёл "на пенсию".
🔥39👍9🤡3👎1👏1
Сейчас в основном консультирую, выступаю ментором и веду канал. Участвую в ПК конференций по системному анализу: Flow, ЛАФ, WAW. Сделал несколько топовых докладов (см. закреп). Первым написал про применение ChatGPT для задач аналитика, архитектора и продакта (сейчас Claude дает лучшие результаты). Провожу тренинги в школе Systems.Education. Соавтор книги "Цифровое качество" (к сожалению, пока что нет в продаже, что-то там с авторскими правами).
Что меня в основном интересует на сегодня: как же, всё-таки, мы создаём эти ИТ-системы и продукты? Как это всё происходит, и как должно происходить правильно, особенно в самом начале? Как разделить роли? Что должен делать разработчик, что архитектор, что продакт, что аналитик? Как устроен пресловутый SDLC? Работает ли agile? Как, блин, понять, что нужно этим пользователям и как им это дать?
Мои убеждения:
1. Требований объективно не существует. Тем более нельзя их "собрать", "выявить" или "извлечь". То, что мы называем требованиями — это высказывания о желаемом поведении системы, то есть, "собирая" требования — мы на самом деле изучаем деятельность людей и проектируем решение для поддержки этой деятельности, решения проблем в ней.
2. Идеальный вариант работы: небольшие команды без жесткого разделения ролей, которые могут сообща накинуться на проблему и придумать её решение. Не числом, а умением. Небольшая группа высококлассных спецов может реально быть в 10 раз быстрее и эффективнее, я это лично видел.
3. Если уж вы решили заниматься требованиями up front — я знаю много техник, которые позволят не пропустить важные требования и избежать недопонимания. Я про них часто рассказываю в канале.
4. Всё, что написано в книжках, нужно рассматривать скептически: умозрительные модели могут вообще никак не соответствовать реальной практике. Я верю в эмпирические исследования и стараюсь их изучать (и иногда пишу про них во второй канал: https://news.1rj.ru/str/yksdailylinks).
5. Любой стандарт или Body of Knowledge лучше книги: во-первых, там будет выжимка без воды, во-вторых — обычно стандарты всё же хоть как-то опираются на реальную практику, а не только на авторские идеи. К счастью, многие стандарты переведены и свободно доступны на русском языке.
Если у вас есть интерес в изучении того, как на самом деле устроен процесс создания систем в этом нашем ИТ, или вы знаете, где это изучают (обычно это какой-то университет) — рад буду познакомиться и что-то поделать вместе! А то у нас скептически относятся к независимым исследователям, нужно обязательно аффилироваться с какой-то организацией.
Что меня в основном интересует на сегодня: как же, всё-таки, мы создаём эти ИТ-системы и продукты? Как это всё происходит, и как должно происходить правильно, особенно в самом начале? Как разделить роли? Что должен делать разработчик, что архитектор, что продакт, что аналитик? Как устроен пресловутый SDLC? Работает ли agile? Как, блин, понять, что нужно этим пользователям и как им это дать?
Мои убеждения:
1. Требований объективно не существует. Тем более нельзя их "собрать", "выявить" или "извлечь". То, что мы называем требованиями — это высказывания о желаемом поведении системы, то есть, "собирая" требования — мы на самом деле изучаем деятельность людей и проектируем решение для поддержки этой деятельности, решения проблем в ней.
2. Идеальный вариант работы: небольшие команды без жесткого разделения ролей, которые могут сообща накинуться на проблему и придумать её решение. Не числом, а умением. Небольшая группа высококлассных спецов может реально быть в 10 раз быстрее и эффективнее, я это лично видел.
3. Если уж вы решили заниматься требованиями up front — я знаю много техник, которые позволят не пропустить важные требования и избежать недопонимания. Я про них часто рассказываю в канале.
4. Всё, что написано в книжках, нужно рассматривать скептически: умозрительные модели могут вообще никак не соответствовать реальной практике. Я верю в эмпирические исследования и стараюсь их изучать (и иногда пишу про них во второй канал: https://news.1rj.ru/str/yksdailylinks).
5. Любой стандарт или Body of Knowledge лучше книги: во-первых, там будет выжимка без воды, во-вторых — обычно стандарты всё же хоть как-то опираются на реальную практику, а не только на авторские идеи. К счастью, многие стандарты переведены и свободно доступны на русском языке.
Если у вас есть интерес в изучении того, как на самом деле устроен процесс создания систем в этом нашем ИТ, или вы знаете, где это изучают (обычно это какой-то университет) — рад буду познакомиться и что-то поделать вместе! А то у нас скептически относятся к независимым исследователям, нужно обязательно аффилироваться с какой-то организацией.
❤38👍27🔥9👎3👏1
Продолжаю про явное и неявное знание: и вот когда вы считаете, что уже выявили все требования и проработали интерфейс (может быть, даже с дизайнером), и приносите его показывать пользователям, вы считаете, что это уже конец, вся работа сделана.
А для ваших заказчиков в этот момент работа только и начинается! До этого они что-то вам рассказывали, это ничего не значит. А теперь им есть на что посмотреть, есть к чему отнестись. Тут они могут как-то соотнести то, что видят, с тем, как они работают. Знания вытащили из их голов и обособили, эксплицировали. Люди впервые увидели свои неявные знания отдельно от себя и удивились. Теперь их нужно изучить, исправить некоторые моменты, а главное — теперь им понятно, как это будет выглядеть и над чем будет идти работа (над внутренним устройством системы работа пользователей идти не может — оно непредставимо или представимо превратно, если только пользователь сам не был когда-то программистом).
Тут возникает острый конфликт: аналитик думал, что работа уже почти закончена, а пользователь — что работа только началась. Эта мысль поражает неопытного аналитика до глубины души и зачастую выглядит, как издевательство. Особенно когда у пользователей не очень много времени, и встречи по согласованию (как думает аналитик, а на самом деле — по разработке интерфейсов и дополнительных требований) происходят редко. Тут и сроки работ начинают затягиваться, и взаимное недовольство растет.
Что с этим делать? Во-первых, понять и признать, что это происходит. Это, в первую очередь, совет руководителям — а то у них в плане записано обычно "первая встреча — сбор требований, 2 часа", "вторая встреча — согласование экранов, 2 часа", и дальше уже отдали в разработку. Как бы не так.
Во-вторых — ну, как-то нужно решать. Сложно за одну встречу и про требования поговорить, и сразу первичное решение предложить, которое на самом деле только повод поговорить про настоящие требования. Что можно сделать:
➡️ честно запланировать дополнительно 2-3 встречи уже после первоначального эскизного решения;
➡️ сделать "домашнюю работу", и приходить на первую встречу уже с заготовками решения, хотя бы примерными, хотя бы аналогами. Если вы работаете в имеющихся системах — можете показать, как выглядят интерфейсы в них, и обсудить, на что будет похож интерфейс для новой задачи. Если у вас есть дизайн-система — покажите элементы из неё. Если вы делаете новую систему — покажите что-то, что может быть похожим по смыслу. Для системы анализа ЭКГ я использовал в качестве источника вдохновения музыкальный редактор. Если у вас есть бумажные формы, которые вы будете переносить в электронную форму — распечатайте их, покажите, как они могут лечь в интерфейс — вот прямо ножницами порежьте в вклейте в распечатку типовых форм. Ножницы и клей — великая вещь! Всех с началом учебного года, кстати. Если уж совсем ничего нет — пробуйте лего, человечков из настолок и т.п. Да даже стикеры лучше, чем просто текст! На картинке — первая схема "Открытого образования". Сразу стало многое понятнее.
В-третьих — идеальный вариант, это Google Design Sprint или что-то аналогичное. Да, на 5 дней отключиться от рабочих процессов может быть сложно. С другой стороны — ездите же вы на конференции и ходите на тренинги, и ничего. А с точки зрения скорости прохода (времени от идеи до постановки) — выиграете несколько недель.
А для ваших заказчиков в этот момент работа только и начинается! До этого они что-то вам рассказывали, это ничего не значит. А теперь им есть на что посмотреть, есть к чему отнестись. Тут они могут как-то соотнести то, что видят, с тем, как они работают. Знания вытащили из их голов и обособили, эксплицировали. Люди впервые увидели свои неявные знания отдельно от себя и удивились. Теперь их нужно изучить, исправить некоторые моменты, а главное — теперь им понятно, как это будет выглядеть и над чем будет идти работа (над внутренним устройством системы работа пользователей идти не может — оно непредставимо или представимо превратно, если только пользователь сам не был когда-то программистом).
Тут возникает острый конфликт: аналитик думал, что работа уже почти закончена, а пользователь — что работа только началась. Эта мысль поражает неопытного аналитика до глубины души и зачастую выглядит, как издевательство. Особенно когда у пользователей не очень много времени, и встречи по согласованию (как думает аналитик, а на самом деле — по разработке интерфейсов и дополнительных требований) происходят редко. Тут и сроки работ начинают затягиваться, и взаимное недовольство растет.
Что с этим делать? Во-первых, понять и признать, что это происходит. Это, в первую очередь, совет руководителям — а то у них в плане записано обычно "первая встреча — сбор требований, 2 часа", "вторая встреча — согласование экранов, 2 часа", и дальше уже отдали в разработку. Как бы не так.
Во-вторых — ну, как-то нужно решать. Сложно за одну встречу и про требования поговорить, и сразу первичное решение предложить, которое на самом деле только повод поговорить про настоящие требования. Что можно сделать:
В-третьих — идеальный вариант, это Google Design Sprint или что-то аналогичное. Да, на 5 дней отключиться от рабочих процессов может быть сложно. С другой стороны — ездите же вы на конференции и ходите на тренинги, и ничего. А с точки зрения скорости прохода (времени от идеи до постановки) — выиграете несколько недель.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍26❤7🔥3😁1
Как согласовать интерфейсы. Ну ладно, мы разобрались, что, когда пользователь впервые видит интерфейс будущей системы, он не воспринимает это, как финальную версию — а скорее как повод наконец-то подумать, как оно на самом деле будет работать (если вы, конечно, заранее не прорабатывали именно процесс решения задачи, а просто "собирали требования").
Но, допустим, первое впечатление уже получено, и уточняющие требования собраны, и всё уже дважды переделано и вроде мы дошли до стадии утверждения интерфейсов. И с этим очень часто возникают большие проблемы. Они возникают у аналитиков, у дизайнеров и иногда даже у продактов, как ни удивительно. Потому что вместо того, чтобы подтвердить и согласиться, стейкхолдеры в очередной раз начинают просить передвинуть кнопку, добавить ещё пару полей и поиграть со шрифтами. И конца этому не видно.
Что здесь обычно происходит? А происходит неуправляемая встреча. Как такая встреча может быть устроена?
❌ Дизайнер или аналитик просто показывает экран системы. Ну вот мы сделали вот такой экран, есть к нему замечания? Это прямо мощная подача — ведь если стейкхолдер скажет "нет", это может значить, что он что, не заинтересован в системе? Или не успел разобраться, и это сейчас замечаний нет, а потом появятся? Дали ли мы время на то, чтобы ознакомиться? Знаем ли мы сами — каких замечаний мы от этого стейкхолдера хотим услышать? Ещё хуже вопрос "вам нравится?" Тут мы полностью снимаем с себя ответственность и отдаемся в руки человека на другой стороне.
Так быть не должно. Эксперты здесь мы. Мы спроектировали всё правильно — красиво, удобно и логично, и мы за это отвечаем. Не нужно перекладывать решение на человека, который в нём не специалист.
❌ Аналитик показывает экран и начинает рассказывать последовательно про каждый элемент. Не надо так. Люди видят, что нарисовано на прототипе. И понимают, для чего каждый элемент нужен. А если не понимает — кажется, у нас есть проблема. Вот только объяснение делу не поможет — ведь в реальной жизни аналитика или дизайнера рядом не будет, чтобы объяснить, что тут зачем. А визуально человек воспринимает информацию гораздо быстрее, чем на слух. Пока вы рассказываете про каждый элемент, ваш визави уже рассмотрел весь экран, и теперь скучает.
✔️ Как правильно построить презентацию интерфейсов:
1. Рассказать, для каких пользователей создан этот интерфейс (для какой роли или персоны) и в какой ситуации этот пользователь находится, когда использует этот интерфейс.
2. Перечислить сценарии, которые пользователи могут выполнить при помощи этого интерфейса. Обычно есть 1-2 основных сценария и дополнительные, куда входят граничные ситуации, альтернативы, исправления и настройки.
3. Демонстрация прохождения сценария пользователем с какой-то ролью. В качестве пользователя выступает аналитик, либо это предлагается сделать одному из согласующих. Сценарий показывается по шагам, при переходе с одного шага на другой можно спросить у зрителей — понятно ли, как перейти к следующему шагу (как вернуться на предыдущий, как исправить что-то или посмотреть дополнительную информацию). Это закрытый вопрос, он предполагает ответ "да"/"нет". Если на этапе разработки требований вы задавали в основном открытые вопросы, на этапе согласования лучше задавать закрытые вопросы. Теперь это не рассуждения, это вопросы на констатацию факта. Задаем конкретные вопросы — понятен ли этот переход, ясно ли, где мы сейчас, что тут самое важное, где ошибка. Все вопросы на уточнение и выяснение вы, надеюсь, задали заранее.
Если стейкхолдер стремится высказать своё замечание, возвращайте его в ту же схему: про какую роль он говорит? В какой ситуации? Какая цель у пользователя? Что он делает? Что происходит, и что он ожидал?
Часто оказывается, что либо ситуация надуманная и так не бывает, либо в сознании у критика спутаны несколько ролей, либо, возможно, мы действительно пропустили какую-то важную ветвь сценария.
Конечно, про формат нужно предупредить участников заранее. Описание контекста, ролей пользователей и сценариев для демонстрации заранее отправить. И про формат обратной связи рассказать.
Но, допустим, первое впечатление уже получено, и уточняющие требования собраны, и всё уже дважды переделано и вроде мы дошли до стадии утверждения интерфейсов. И с этим очень часто возникают большие проблемы. Они возникают у аналитиков, у дизайнеров и иногда даже у продактов, как ни удивительно. Потому что вместо того, чтобы подтвердить и согласиться, стейкхолдеры в очередной раз начинают просить передвинуть кнопку, добавить ещё пару полей и поиграть со шрифтами. И конца этому не видно.
Что здесь обычно происходит? А происходит неуправляемая встреча. Как такая встреча может быть устроена?
Так быть не должно. Эксперты здесь мы. Мы спроектировали всё правильно — красиво, удобно и логично, и мы за это отвечаем. Не нужно перекладывать решение на человека, который в нём не специалист.
1. Рассказать, для каких пользователей создан этот интерфейс (для какой роли или персоны) и в какой ситуации этот пользователь находится, когда использует этот интерфейс.
2. Перечислить сценарии, которые пользователи могут выполнить при помощи этого интерфейса. Обычно есть 1-2 основных сценария и дополнительные, куда входят граничные ситуации, альтернативы, исправления и настройки.
3. Демонстрация прохождения сценария пользователем с какой-то ролью. В качестве пользователя выступает аналитик, либо это предлагается сделать одному из согласующих. Сценарий показывается по шагам, при переходе с одного шага на другой можно спросить у зрителей — понятно ли, как перейти к следующему шагу (как вернуться на предыдущий, как исправить что-то или посмотреть дополнительную информацию). Это закрытый вопрос, он предполагает ответ "да"/"нет". Если на этапе разработки требований вы задавали в основном открытые вопросы, на этапе согласования лучше задавать закрытые вопросы. Теперь это не рассуждения, это вопросы на констатацию факта. Задаем конкретные вопросы — понятен ли этот переход, ясно ли, где мы сейчас, что тут самое важное, где ошибка. Все вопросы на уточнение и выяснение вы, надеюсь, задали заранее.
Если стейкхолдер стремится высказать своё замечание, возвращайте его в ту же схему: про какую роль он говорит? В какой ситуации? Какая цель у пользователя? Что он делает? Что происходит, и что он ожидал?
Часто оказывается, что либо ситуация надуманная и так не бывает, либо в сознании у критика спутаны несколько ролей, либо, возможно, мы действительно пропустили какую-то важную ветвь сценария.
Конечно, про формат нужно предупредить участников заранее. Описание контекста, ролей пользователей и сценариев для демонстрации заранее отправить. И про формат обратной связи рассказать.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍38🔥14❤13
Перевел статью создателя mermaid.js про UML и диаграмму последовательности: https://habr.com/ru/articles/840890/
Он там ещё год назад собрал все мнения и высказывания по поводу "смерти UML", так что можно как обзор использовать, и по ссылкам уходить читать, если интересно.
Ну и про диаграмму последовательности пишет ровно то, что я на каждом тренинге говорю: идите от happy path, давайте общую картину, не сваливайтесь в детали.
В общем, буду рад обратной связи, а какие-то комментарии могу и Кнуту передать — я списался с ним и спросил разрешение на перевод.
Он там ещё год назад собрал все мнения и высказывания по поводу "смерти UML", так что можно как обзор использовать, и по ссылкам уходить читать, если интересно.
Ну и про диаграмму последовательности пишет ровно то, что я на каждом тренинге говорю: идите от happy path, давайте общую картину, не сваливайтесь в детали.
В общем, буду рад обратной связи, а какие-то комментарии могу и Кнуту передать — я списался с ним и спросил разрешение на перевод.
Хабр
Диаграммы последовательности — единственная хорошая вещь, которую UML привнес в разработку ПО
От переводчика: Я веду телеграмм‑канал, посвященный системному анализу, и провожу тренинги, и в какой‑то момент задался вопросом — а актуален ли сейчас UML? Если посмотреть...
❤14🔥14👍5🤔1
Папка про agile и стратегическое управление у нас уже была, а теперь — хит! Папка каналов про системный анализ. Топовые каналы по системному и бизнес-анализу, целых 22 штуки, в папке AnalystHub.
Большинство, что приятно — авторские, то есть это не просто перепост контента, а личные мнения, опыт и экспертиза. Впрочем, и перепост иногда бывает интересным, когда хорошо подбирается под актуальные темы, не будем этим пренебрегать.
У Димы Безуглого (канал которого был в предыдущей подборке) есть отличный пост про то, как обращаться с папками. Лучше даже не напишешь:
Я делаю точно так же. Конечно, у меня есть своя папка по системному анализу, и новые каналы, если они мне понравились, я перекладываю в неё. Я когда-то сделал первую общую папку по теме системного анализа, когда Telegram только запустил их шэринг, но у меня там было каналов и чатов раза в полтора меньше, так что число авторов растет! (А у некоторых, я видел, есть папки и по 44 канала! Там вообще всё есть, наверное).
Папки у меня организованы так (вдруг вам интересно):
* папка по системному анализу
* папка по архитектуре
* папка по управлению продуктами, маркетингу и стратегии
* папка с каналами по образованию и edTech
* папка с новостными каналами и обзорами финансовых рынков
* несколько папок с чатами и контактами по актуальным и предыдущим проектам
* несколько общих папок, которые пока не разобрал
Почти все каналы, кроме пары-тройки, за которыми я в данный слежу, у меня стоят на mute. Но я всё равно многие просматриваю, стараюсь поддерживать в папках Zero Unread. Хотя с чатами это не получается, в активный чат всегда что-то валится. Ещё, к сожалению, есть каналы, куда валится какая-то прорва рекламы, среди неё даже теряется интересный контент. Я всё понимаю, это работа, ничего личного, но это уже какой-то перебор. Сохраняю их только для рабочих нужд: посмотреть, что рекламируют, как рынок выглядит, как вообще такие проекты живут, что делают для привлечения подписчиков, какие показатели.
В общем, в AnalystHub ничего такого нет, как я уже сказал — в основном авторские каналы. Так что — подписывайтесь, читайте, оставляйте себе нужные, прокачивайтесь в системном анализе и смежных дисциплинах!
Большинство, что приятно — авторские, то есть это не просто перепост контента, а личные мнения, опыт и экспертиза. Впрочем, и перепост иногда бывает интересным, когда хорошо подбирается под актуальные темы, не будем этим пренебрегать.
У Димы Безуглого (канал которого был в предыдущей подборке) есть отличный пост про то, как обращаться с папками. Лучше даже не напишешь:
Шаг 1. Добавляю папку.
Шаг 2. Каждый день заглядываю в папку и читаю 1-2 канала (в такси или в качестве перерыва).
Шаг 3. Если мое - переношу в свою папку по теме, если нет - покидаю канал.
Шаг 4. Если папка кончилась, иду смотреть те каналы, на которые раньше подписался )
Я делаю точно так же. Конечно, у меня есть своя папка по системному анализу, и новые каналы, если они мне понравились, я перекладываю в неё. Я когда-то сделал первую общую папку по теме системного анализа, когда Telegram только запустил их шэринг, но у меня там было каналов и чатов раза в полтора меньше, так что число авторов растет! (А у некоторых, я видел, есть папки и по 44 канала! Там вообще всё есть, наверное).
Папки у меня организованы так (вдруг вам интересно):
* папка по системному анализу
* папка по архитектуре
* папка по управлению продуктами, маркетингу и стратегии
* папка с каналами по образованию и edTech
* папка с новостными каналами и обзорами финансовых рынков
* несколько папок с чатами и контактами по актуальным и предыдущим проектам
* несколько общих папок, которые пока не разобрал
Почти все каналы, кроме пары-тройки, за которыми я в данный слежу, у меня стоят на mute. Но я всё равно многие просматриваю, стараюсь поддерживать в папках Zero Unread. Хотя с чатами это не получается, в активный чат всегда что-то валится. Ещё, к сожалению, есть каналы, куда валится какая-то прорва рекламы, среди неё даже теряется интересный контент. Я всё понимаю, это работа, ничего личного, но это уже какой-то перебор. Сохраняю их только для рабочих нужд: посмотреть, что рекламируют, как рынок выглядит, как вообще такие проекты живут, что делают для привлечения подписчиков, какие показатели.
В общем, в AnalystHub ничего такого нет, как я уже сказал — в основном авторские каналы. Так что — подписывайтесь, читайте, оставляйте себе нужные, прокачивайтесь в системном анализе и смежных дисциплинах!
👍8❤4🤗3👎2🔥1
Недавно опять столкнулся с фразой "списать часы" — мол, коллеги для меня что-то сдедали, не списывая часов, то есть, считай, даром, по-товарищески.
Это в компании, где на каждую работу нужно "списывать" время, и набрать за день 8 часов.
Я в таких компаниях никогда не работал, да и не смог бы, наверное. Хотя человек — существо крайне адаптивное, и найдет, как обхитрить любую систему.
И об этом пишет Пол Грэм в своем свежем эссе 'Founder mode', которое все теперь обсуждают, и от которого у многих неслабо пригорело.
Есть два режима управления компанией, пишет Грэм: режим основателя и режим менеджера.
Все книги по управлению написаны менеджерами для менеджеров. А у менеджеров основная работа — передать задачи куда-то вниз по иерархии, как в черный ящик, и выдать отчет (желательно оптимистичный) наверх. Стимулирование удач и наказание за провалы приводит к тому, что менеджеры становятся профессиональными лжецами, а вместе с ними и работники.
А вместо объединения усилий для работы над единой целью, люди начинают "списывать часы", торговаться, играть в политику, подставлять друг друга, сваливать на коллег неудачи и производить собственный пиар вместо настоящих результатов.
Хуже всего в такой обстановке приходится продакту. С одной стороны, он выступает практически фаундером своего продукта, с другой — реально он не фаундер, а наемный менеджер. Ситуация требует невозможного, и либо продакт скатывается в режим менеджера, который особо не за что не отвечает, либо сваливает и долго восстанавливает психологическое равновесие.
Бывают, конечно, редкие варианты моментов свободы, когда ситуация настолько рискованная и ставки настолько высоки, что корпоративная бюрократия на время ослабляет хватку.
Я работал в таких проектах, я вообще легко скатываюсь в режим фаундера. Если нужно для дела — иду на переработки, докапываюсь до деталей, выискиваю разные хитрые способы и потягиваю всех своих друзей-экспертов. Во время разработки "Открытого образования" я вложил свои личные 1000$ в инфраструктуру, когда выделение бюджета задерживалось. Думаете, мне их потом вернули? Как бы не так, меня ещё примерно на столько же оштрафовали после запуска — кое-кому показалось, что некоторые работы можно было выполнить быстрее.
Но любой наемный продакт — всё равно не фаундер. Когда выкладываешь свои кровные за так себе сделанную работу, вот тут резко понимаешь, что нужно что-то с этим делать. Идешь читать книги — а там всё с точки зрения менеджера! Применишь — получишь вранье на вранье. Круг замкнулся.
К сожалению, пишет Грэм, мы в точности не знаем, как работает режим фаундера. Ну, точно известно, что нужно избегать иерархий и лично иметь представление о том, что происходит на каждом уровне. Пример — ретриты Джобса, куда он вытаскивал 200 ключевых сотрудников — не топов, а ключевых сотрудников. Что ещё — мы не знаем, нет ни исследований, ни книг.
Но с отрицательными примерами, я думаю, сталкивались все.
Это в компании, где на каждую работу нужно "списывать" время, и набрать за день 8 часов.
Я в таких компаниях никогда не работал, да и не смог бы, наверное. Хотя человек — существо крайне адаптивное, и найдет, как обхитрить любую систему.
И об этом пишет Пол Грэм в своем свежем эссе 'Founder mode', которое все теперь обсуждают, и от которого у многих неслабо пригорело.
Есть два режима управления компанией, пишет Грэм: режим основателя и режим менеджера.
Все книги по управлению написаны менеджерами для менеджеров. А у менеджеров основная работа — передать задачи куда-то вниз по иерархии, как в черный ящик, и выдать отчет (желательно оптимистичный) наверх. Стимулирование удач и наказание за провалы приводит к тому, что менеджеры становятся профессиональными лжецами, а вместе с ними и работники.
А вместо объединения усилий для работы над единой целью, люди начинают "списывать часы", торговаться, играть в политику, подставлять друг друга, сваливать на коллег неудачи и производить собственный пиар вместо настоящих результатов.
Хуже всего в такой обстановке приходится продакту. С одной стороны, он выступает практически фаундером своего продукта, с другой — реально он не фаундер, а наемный менеджер. Ситуация требует невозможного, и либо продакт скатывается в режим менеджера, который особо не за что не отвечает, либо сваливает и долго восстанавливает психологическое равновесие.
Бывают, конечно, редкие варианты моментов свободы, когда ситуация настолько рискованная и ставки настолько высоки, что корпоративная бюрократия на время ослабляет хватку.
Я работал в таких проектах, я вообще легко скатываюсь в режим фаундера. Если нужно для дела — иду на переработки, докапываюсь до деталей, выискиваю разные хитрые способы и потягиваю всех своих друзей-экспертов. Во время разработки "Открытого образования" я вложил свои личные 1000$ в инфраструктуру, когда выделение бюджета задерживалось. Думаете, мне их потом вернули? Как бы не так, меня ещё примерно на столько же оштрафовали после запуска — кое-кому показалось, что некоторые работы можно было выполнить быстрее.
Но любой наемный продакт — всё равно не фаундер. Когда выкладываешь свои кровные за так себе сделанную работу, вот тут резко понимаешь, что нужно что-то с этим делать. Идешь читать книги — а там всё с точки зрения менеджера! Применишь — получишь вранье на вранье. Круг замкнулся.
К сожалению, пишет Грэм, мы в точности не знаем, как работает режим фаундера. Ну, точно известно, что нужно избегать иерархий и лично иметь представление о том, что происходит на каждом уровне. Пример — ретриты Джобса, куда он вытаскивал 200 ключевых сотрудников — не топов, а ключевых сотрудников. Что ещё — мы не знаем, нет ни исследований, ни книг.
Но с отрицательными примерами, я думаю, сталкивались все.
👍39🔥15❤3
В обсуждении списывания времени проскочило совсем дикое сообщение, что в некоторых компаниях запрещают списывать время на совещания и созвоны. Как при этом набрать 8 часов, я не представляю. А те, кто это придумал, видимо, очень далеки от реальности, и уж точно не читали "Мифический человеко-месяц", с его клёвыми фразами типа "программирование — это не сбор хлопка, эту работу нельзя произвольно делить на любое количество частей, и не общаться в процессе".
Вопросы синхронизации и изучения требований требуют времени. Возьмем строгий фреймворк, например Scrum, который обещает выполнение вдвое большей работы за половину времени (это так книга Сазерленда называлась, 'Scrum: The Art of Doing Twice the Work in Half the Time', это название даже испугались на русский переводить, перевели скромно как "Революционный метод управления проектами"). Вот смотрите, что говорит Scrum Guide для спринта длиной в месяц:
8 часов на планирование спринта;
5 часов на дейлики (15 минут в день * 20 дней);
4 часа — спринт ревью;
3 часа — ретро;
16 часов (10% спринта) — Backlog Refinement, совместная проработка требований всей командой (у вас вообще такое есть? Вы про эту практику слышали?..)
Получается 124 часа в месяц, т.е. 6,2 часа в день на работу. Ну, в хороший день у меня тоже так и получается, и это, наверное, максимум, что можно выжать — реальной работы, я имею в виду. На самом деле, что означает 15-минутный дейли? Это значит, что про зависшую задачу ты успеваешь сказать, что она зависла, и тебе нужно обсудить её с тем-то и тем-то➡️ назначается встреча для решения. Мы же не думаем, что вне ритуалов scrum люди между собой не общаются? Допустим, мы эти встречи тщательно таймбоксим, и их не бывает больше часа в день (ха!). Ещё к этому нужно приплюсовать (или вычесть) время на персональное развитие (1:1, составление планов, выбор конференций/обучения, планирование отпуска и т.п.), кофе и всякую текучку — отведем на это ещё час. Получается примерно 4 часа, что, по моей практике, выглядит уже довольно реалистичным.
Не то чтобы это было хорошо. Но иногда и этих 4 часов нет — например, когда вам дали стажеров или нужно готовить выступление на конференции/внутреннем митапе. В том же скраме, раз мы про него говорим, такими вещами должен заниматься скрам-мастер — убирать из времени команды всё, что мешает (то мебель нужно в новом офисе расставить, то должностную инструкцию себе написать, то распланировать график отпусков на год — всегда есть, чем заняться).
Но знают ли об этом люди, которые берутся трекать время? Мне кажется, первый шаг в любом деле — признание реального положения вещей. Ну не производят люди код или аналитические документы 5 дней по 8 часов. Вон и Scrum говорит — максимально теоретически возможное время — чуть больше 6 часов, к нему нужно стремиться.
И это нормально. При объяснении теории ограничений (ToC) приводят такую аналогию, мне она очень понравилась: как быстрее всего вылить воду из бутылки? Просто перевернуть — вода будет булькать, выходить толчками, т.е., процесс будет регулярно останавливаться и перезапускаться. Если вы раскрутите бутылку и сделаете воронку — вода выльется почти вдвое быстрее, хотя в центре будет пустота — горлышко не будет заполнено. Можно вставить соломинку — горлышко ещё сильнее сузится, но в бутылку будет поступать свежий воздух, и поток станет равномерным. Если в соломинку ещё и подуть — скорость ещё увеличится.
Парадокс: чтобы скорость была выше, часть горлышка должна оставаться свободной. Так и в управлении: ваша цель ведь не в том, чтобы загрузить работников на 100%, а чтобы работа делалась быстрее. Чем равномернее будет поток — тем быстрее получим результат работы. Да, для этого нужно дать приток свежего воздуха 😉 И не занимать полностью весь доступный ресурс. Всё равно не получится, будут остановки и перезапуски. Так не лучше ли это признать с самого начала, и сфокусироваться на гладкости и скорости потока, а не на загрузке людей?
Вопросы синхронизации и изучения требований требуют времени. Возьмем строгий фреймворк, например Scrum, который обещает выполнение вдвое большей работы за половину времени (это так книга Сазерленда называлась, 'Scrum: The Art of Doing Twice the Work in Half the Time', это название даже испугались на русский переводить, перевели скромно как "Революционный метод управления проектами"). Вот смотрите, что говорит Scrum Guide для спринта длиной в месяц:
8 часов на планирование спринта;
5 часов на дейлики (15 минут в день * 20 дней);
4 часа — спринт ревью;
3 часа — ретро;
16 часов (10% спринта) — Backlog Refinement, совместная проработка требований всей командой (у вас вообще такое есть? Вы про эту практику слышали?..)
Получается 124 часа в месяц, т.е. 6,2 часа в день на работу. Ну, в хороший день у меня тоже так и получается, и это, наверное, максимум, что можно выжать — реальной работы, я имею в виду. На самом деле, что означает 15-минутный дейли? Это значит, что про зависшую задачу ты успеваешь сказать, что она зависла, и тебе нужно обсудить её с тем-то и тем-то
Не то чтобы это было хорошо. Но иногда и этих 4 часов нет — например, когда вам дали стажеров или нужно готовить выступление на конференции/внутреннем митапе. В том же скраме, раз мы про него говорим, такими вещами должен заниматься скрам-мастер — убирать из времени команды всё, что мешает (то мебель нужно в новом офисе расставить, то должностную инструкцию себе написать, то распланировать график отпусков на год — всегда есть, чем заняться).
Но знают ли об этом люди, которые берутся трекать время? Мне кажется, первый шаг в любом деле — признание реального положения вещей. Ну не производят люди код или аналитические документы 5 дней по 8 часов. Вон и Scrum говорит — максимально теоретически возможное время — чуть больше 6 часов, к нему нужно стремиться.
И это нормально. При объяснении теории ограничений (ToC) приводят такую аналогию, мне она очень понравилась: как быстрее всего вылить воду из бутылки? Просто перевернуть — вода будет булькать, выходить толчками, т.е., процесс будет регулярно останавливаться и перезапускаться. Если вы раскрутите бутылку и сделаете воронку — вода выльется почти вдвое быстрее, хотя в центре будет пустота — горлышко не будет заполнено. Можно вставить соломинку — горлышко ещё сильнее сузится, но в бутылку будет поступать свежий воздух, и поток станет равномерным. Если в соломинку ещё и подуть — скорость ещё увеличится.
Парадокс: чтобы скорость была выше, часть горлышка должна оставаться свободной. Так и в управлении: ваша цель ведь не в том, чтобы загрузить работников на 100%, а чтобы работа делалась быстрее. Чем равномернее будет поток — тем быстрее получим результат работы. Да, для этого нужно дать приток свежего воздуха 😉 И не занимать полностью весь доступный ресурс. Всё равно не получится, будут остановки и перезапуски. Так не лучше ли это признать с самого начала, и сфокусироваться на гладкости и скорости потока, а не на загрузке людей?
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍68❤20🤡3💯1
Ну всё, можно считать себя экспертом: Карл Вигерс говорит от требованиях то же и теми же словами, что и я (https://news.1rj.ru/str/systemswing/450), правда, чуть раньше — в 2021 году:
Далее он пишет, что с первого раза всё узнать не получится, что нужно вернуться к стейкхолдерам, преодолеть их "Ну мы же это уже обсуждали!", но без этого никак. Выявление требований, — пишет Вигерс, — это как очистка луковицы, только наоборот: чем больше слоев счищаешь, тем больше она становится.
Это из последней книги Вигерса: Software Development Pearls: Lessons from Fifty Years of Software Experience ("Жемчужины разработки: Чему мы научились за 50 лет создания ПО")
Книга, кажется, небезынтересная, придётся читать. Приведенная цитата — это Урок 11, а дальше он пишет, что
И что идеальный вариант — когда разработчик один, пользователь один, они сидят за соседними столами, и пользователю можно сразу показать готовый результат. Тогда и требования не нужны. И к этой идеальной картине нужно стремиться — что я готов подтвердить, это и правда самый лучший способ!
В общем, любопытно. Напишу больше, как дочитаю📕
Люди часто говорят о сборе требований к программному проекту, но это создает неверное впечатление. Слово «сбор» предполагает, что требования уже лежат где-то в готовом виде и только и ждут, чтобы их подобрали. Когда я слышу, как кто-то говорит «сбор требований», в моем воображении всплывает картинка сбора цветов или охоты за пасхальными яйцами. Увы, это не так просто.
Требования редко существуют в сознании пользователей в полностью сформированном виде, готовом для передачи бизнес-аналитику или команде разработки, только спроси. Создание набора требований определенно подразумевает этап сбора некой информации, но также включает открытие и изобретение (курсив мой. Смотрите, даже Вигерс пишет, что мы изобретаем требования!). Термин «выявление требований» (requirements elicitation) точнее описывает, как люди из ИТ сотрудничают с заинтересованными сторонами, чтобы изучить, как те работают сейчас, и определить, какие возможности должна предоставлять будущая программная система.
Согласно словарю The American Heritage Dictionary of the English Language (2020), под словом elicitation подразумевается выманивание, вытягивание или провоцирование. Слова «выманивание» и «вытягивание» точнее описывают процесс, чем слова выявление или сбор.
Самые бесполезные вопросы, которые не следует задавать при изучении требований: «Чего вы хотите?» и «Каковы ваши требования?». Такие расплывчатые вопросы вызывают поток множества случайных — но важных, конечно — сведений, смешанных с посторонней информацией и приправленных невысказанными предположениями. Бизнес-аналитик не просто записывает все, что ему говорят заинтересованные стороны. Опытный БА фасилитирует обсуждение, направляя участников на раскрытие имеющего отношение к проблеме знания в структурированном виде.
Далее он пишет, что с первого раза всё узнать не получится, что нужно вернуться к стейкхолдерам, преодолеть их "Ну мы же это уже обсуждали!", но без этого никак. Выявление требований, — пишет Вигерс, — это как очистка луковицы, только наоборот: чем больше слоев счищаешь, тем больше она становится.
Это из последней книги Вигерса: Software Development Pearls: Lessons from Fifty Years of Software Experience ("Жемчужины разработки: Чему мы научились за 50 лет создания ПО")
Книга, кажется, небезынтересная, придётся читать. Приведенная цитата — это Урок 11, а дальше он пишет, что
Две основные практики выявления требований — телепатия и ясновидение. Они не работают. (Урок 13)
Большая группа людей не способна организованно покинуть горящую комнату, не говоря уж о том, чтобы коллективно сформулировать какое-то требование (Урок 14)
И что идеальный вариант — когда разработчик один, пользователь один, они сидят за соседними столами, и пользователю можно сразу показать готовый результат. Тогда и требования не нужны. И к этой идеальной картине нужно стремиться — что я готов подтвердить, это и правда самый лучший способ!
В общем, любопытно. Напишу больше, как дочитаю
Please open Telegram to view this post
VIEW IN TELEGRAM
👍35❤17🔥8👏1
Вообще вот эта зацикленность на отработанных часах — типичное проявление когнитивного искажения "подмена атрибута" (Attribute substitution). В русской Википедии про него статьи нет, поэтому российские специалисты по когнитивным искажениям, которых вы могли слышать на каких-нибудь конференциях, про него никогда не упоминают.
Подмена (или подстановка) атрибута — это когда мы вместо какого-то сложного явления, о котором энергозатратно или непонятно как думать, или оно сложнее доступно для наблюдения, подставляем явление более простое в понимании и доступное. Но другое. И происходит это для мозга незаметно.
Это, например, объясняет множество оптических иллюзий, связанных с оценкой размера объектов, показанных в перспективе (одинаковые по размеру объекты кажутся меньше или больше в зависимости от расположения). Мозг натренирован распознавать трехмерные объекты, он их и распознает, подставляя 3D-модель вместо 2D-рисунков.
В управлении происходит то же самое: нас ведь должны интересовать не отработанные часы, а число выполненных задач. Ну, вдумайтесь в эту фразу: "мы вам платим за отработанное время". Ну бред же. А ещё точнее — даже число успешно выполненных задач так себе показатель, по настоящему нас должна интересовать принесенная польза. Какое-то время назад велись даже разговоры про Agile Manifesto 2.1, с тезисом Business value over working software — Ценность для бизнеса важнее работающего ПО.
Поэтому разговоры о подсчете часов — это подмена непонятного и недоступного "числа задач" (список которых не ведется, да и что считать задачей?..) или, спаси и помилуй, некоей "бизнес-ценности", на простые и понятные часы. Часы легко измерить, очень просто понять и объяснить другим, что это такое, да и пронаблюдать проще простого: вот же, сидит человек, часы идут!
Но если вам вдруг нужно оценить сроки завершения проекта, все эти часы работают очень плохо (про это было множество исследований — любая другая оценка, не привязанная ко времени, дает более точный результат). Человеку вообще сложно оценивать вещи и предсказывать, более-менее хорошо это начинает получаться после долгих специальных тренировок.
Лучше всего — не предсказывать, а экстраполировать. Начать с каких-то данных, и продолжить их в будущее. Когда-то давно я подсмотрел у Макса Дорофеева (Cartmendum) классный инструмент оценки сроков завершения проекта — Enhanced Burn-Down Chart, расширенная диаграмма сгорания работ. Идея очень простая: сравниваем, сколько задач выполнено, и сколько новых насыпалось. Где их линии трендов пересекутся — там проект и закончится, с большой вероятностью. А если не пересекутся — не закончится никогда. Применял его на нескольких проектах — работает, как часы. Против математики не попрёшь!
Подмена (или подстановка) атрибута — это когда мы вместо какого-то сложного явления, о котором энергозатратно или непонятно как думать, или оно сложнее доступно для наблюдения, подставляем явление более простое в понимании и доступное. Но другое. И происходит это для мозга незаметно.
Это, например, объясняет множество оптических иллюзий, связанных с оценкой размера объектов, показанных в перспективе (одинаковые по размеру объекты кажутся меньше или больше в зависимости от расположения). Мозг натренирован распознавать трехмерные объекты, он их и распознает, подставляя 3D-модель вместо 2D-рисунков.
В управлении происходит то же самое: нас ведь должны интересовать не отработанные часы, а число выполненных задач. Ну, вдумайтесь в эту фразу: "мы вам платим за отработанное время". Ну бред же. А ещё точнее — даже число успешно выполненных задач так себе показатель, по настоящему нас должна интересовать принесенная польза. Какое-то время назад велись даже разговоры про Agile Manifesto 2.1, с тезисом Business value over working software — Ценность для бизнеса важнее работающего ПО.
Поэтому разговоры о подсчете часов — это подмена непонятного и недоступного "числа задач" (список которых не ведется, да и что считать задачей?..) или, спаси и помилуй, некоей "бизнес-ценности", на простые и понятные часы. Часы легко измерить, очень просто понять и объяснить другим, что это такое, да и пронаблюдать проще простого: вот же, сидит человек, часы идут!
Но если вам вдруг нужно оценить сроки завершения проекта, все эти часы работают очень плохо (про это было множество исследований — любая другая оценка, не привязанная ко времени, дает более точный результат). Человеку вообще сложно оценивать вещи и предсказывать, более-менее хорошо это начинает получаться после долгих специальных тренировок.
Лучше всего — не предсказывать, а экстраполировать. Начать с каких-то данных, и продолжить их в будущее. Когда-то давно я подсмотрел у Макса Дорофеева (Cartmendum) классный инструмент оценки сроков завершения проекта — Enhanced Burn-Down Chart, расширенная диаграмма сгорания работ. Идея очень простая: сравниваем, сколько задач выполнено, и сколько новых насыпалось. Где их линии трендов пересекутся — там проект и закончится, с большой вероятностью. А если не пересекутся — не закончится никогда. Применял его на нескольких проектах — работает, как часы. Против математики не попрёшь!
👍43❤3
Как выглядит на практике работа с Enhanced Burndown Chart.
Попросили меня посмотреть, что с проектом. А то заказчик говорит — уже почти два месяца прошло, а ничего не движется. Первичная диагностика: смотрим, что там "не движется" (картинка 1). Видим, что с 1 по 5 итерации разработка действительно не очень сильно напрягалась, но, тем не менее, выполнила все первоначальные задачи. Видим резкие скачки на 3 и на 7 итерации — заказчик накинул новые требования, которых не было в самом начале.
В принципе, для agile это нормально, но конкретно на этом проекте ситуация с поставкой ценности не очень — заказчик до сих пор не может ничего использовать — нет законченных целостных сценариев (это проблема планирования спринтов, явная ошибка). Ну и первоначально выявленные требования очевидно не полны — можно увидеть, как заказчик смотрит на промежуточный результат, и только в этот момент понимает, что ему нужно (3 итерация).
Это бы не было проблемой, если бы с ожиданиями заказчика заранее поработали, и если бы хотя бы раз в месяц ему выдавали полезные результаты. В принципе, тогда бы и вопроса про сходимость проекта не возникло. Реальные продукты, которые развиваются, могут вообще не сходиться — у них нет финальной точки, после которой разработка останавливается. Но можно выделить промежуточные крупные этапы, сходимость к которым можно оценить.
Команда понимает недовольство заказчика, и пытается решить это, как умеет — сделать побольше задач, возможно — с переработками. Это дает мощный 7 спринт, да и 6 тоже был производительный. Однако в ожидания вновь не очень попали: заказчик в 7 опять накидал новых задач. Ясно, что команда в таком же авральном режиме долго работать не сможет.
Теперь нужно решить, что делать дальше. Варианты (на картинках — прогноз числа задач по спринтам):
* объявить фича-фриз, то есть перестать принимать новые задачи на какое-то время, и закончить те сценарии, которые уже в работе. Заказчику не понравится, но будет хоть какое-то законченное изделие к 11 итерации;
* посмотреть на тренд 7 и 8 итерации, и предположить, что команда уже достаточно выявила потребности заказчика, и дальнейших рывков вниз не будет. Поэтому можем не морозить скоуп, а заодно можем ещё раз напрячься, как мы уже делали на 6-ой итерации. Тогда можем успеть к 12 итерации, но есть значимая вероятность, что проект уедет правее;
* если не напрягаться, но предположить, что новых требований не будет, то мы уезжаем куда-то вдаль, и конца проекту не видно;
* наконец, если совместим фича-фриз и напряжемся, то можем выиграть одну итерацию (11 вместо 12).
Вот такой диагноз и такие варианты действий. Как вы думаете, какой вариант был выбран в реальности?
Попросили меня посмотреть, что с проектом. А то заказчик говорит — уже почти два месяца прошло, а ничего не движется. Первичная диагностика: смотрим, что там "не движется" (картинка 1). Видим, что с 1 по 5 итерации разработка действительно не очень сильно напрягалась, но, тем не менее, выполнила все первоначальные задачи. Видим резкие скачки на 3 и на 7 итерации — заказчик накинул новые требования, которых не было в самом начале.
В принципе, для agile это нормально, но конкретно на этом проекте ситуация с поставкой ценности не очень — заказчик до сих пор не может ничего использовать — нет законченных целостных сценариев (это проблема планирования спринтов, явная ошибка). Ну и первоначально выявленные требования очевидно не полны — можно увидеть, как заказчик смотрит на промежуточный результат, и только в этот момент понимает, что ему нужно (3 итерация).
Это бы не было проблемой, если бы с ожиданиями заказчика заранее поработали, и если бы хотя бы раз в месяц ему выдавали полезные результаты. В принципе, тогда бы и вопроса про сходимость проекта не возникло. Реальные продукты, которые развиваются, могут вообще не сходиться — у них нет финальной точки, после которой разработка останавливается. Но можно выделить промежуточные крупные этапы, сходимость к которым можно оценить.
Команда понимает недовольство заказчика, и пытается решить это, как умеет — сделать побольше задач, возможно — с переработками. Это дает мощный 7 спринт, да и 6 тоже был производительный. Однако в ожидания вновь не очень попали: заказчик в 7 опять накидал новых задач. Ясно, что команда в таком же авральном режиме долго работать не сможет.
Теперь нужно решить, что делать дальше. Варианты (на картинках — прогноз числа задач по спринтам):
* объявить фича-фриз, то есть перестать принимать новые задачи на какое-то время, и закончить те сценарии, которые уже в работе. Заказчику не понравится, но будет хоть какое-то законченное изделие к 11 итерации;
* посмотреть на тренд 7 и 8 итерации, и предположить, что команда уже достаточно выявила потребности заказчика, и дальнейших рывков вниз не будет. Поэтому можем не морозить скоуп, а заодно можем ещё раз напрячься, как мы уже делали на 6-ой итерации. Тогда можем успеть к 12 итерации, но есть значимая вероятность, что проект уедет правее;
* если не напрягаться, но предположить, что новых требований не будет, то мы уезжаем куда-то вдаль, и конца проекту не видно;
* наконец, если совместим фича-фриз и напряжемся, то можем выиграть одну итерацию (11 вместо 12).
Вот такой диагноз и такие варианты действий. Как вы думаете, какой вариант был выбран в реальности?
👍18