В общем, раскрываю интригу предыдущих картинок. ТЗ на самом деле было в двух вариантах: одно детальное, другое верхнеуровневое.
Детальное ТЗ:
В принципе, несомненно, у всех что-то получилось, Что можно отметить:
1) Участники были достаточно опытные, чтобы не наваливать вперемешку коров, цветы и птиц, даже если они вперемешку указаны в ТЗ, и в целом картина почти ни у кого не разваливается, как часто бывает в иллюстрациях к этой игре;
2) Команда с летающими коровами пошутила уже надо мной: "
3) Заказчик не проверил заранее наличие необходимых компетенций в команде! Ну не умеют люди рисовать коров, это не проблема людей, это проблема заказчика, который не провел предварительную квалификацию участников тендера.
4) Обычно этой игрой иллюстрируют снижение креативности и полезности продукта при точном выполнении ТЗ; в целом, эффект прослеживается: есть некоторая монотонность выполнения задания по детализированному ТЗ, а также нарушение ракурса — какие-то цветы видны сбоку, какие-то сверху; какие-то огромны по сравнению с коровами, какие-то мелкие — то есть, при отсутствии указания общей цели системы возникают диспропорции и отсутствует единая точка зрения, мы через систему смотрим на мир с какой точки зрения — сверху или сбоку?.. Не понимая задачу, не построишь правильное отражение мира, хотя все отдельные элементы на месте.
5) Из всех команд только одна нашла возможность опросить заказчика (хотя я заранее говорил о такой возможности), и чаще именно работу этой команды признают наиболее подходящей с точки зрения заказчика.
Вот такое получилось забавное упражнение. С точки зрения чистоты эксперимента научности в нём нет никакой, но как иллюстрация — явно наводит на мысли 🤔
Детальное ТЗ:
Нарисуйте прекрасный летний луг, на котором расположены:
* 10 синих цветов с 5 лепестками каждый
* 5 синих цветов с 6 лепестками каждый
* 12 красных цветов с 6 лепестками каждый
* 2 коровы с 3 чёрными пятнами на боку
* 1 корова с 5 чёрными пятнами на боку
* 3 летящих птицы в левом верхнем углу
* 2 птицы посередине
* 1 солнце с 5 лучами в правом верхнем углу
Верхнеуровневое ТЗ:Нарисуйте прекрасный летний луг с красными и синими цветами в зелёной траве, несколькими коровами и птицами в небе, и сияющим солнцем.
Эта картина должна напоминать нашему клиенту о его детстве в деревне.
Что получилось — можете увидеть в предыдущем посте 😆В принципе, несомненно, у всех что-то получилось, Что можно отметить:
1) Участники были достаточно опытные, чтобы не наваливать вперемешку коров, цветы и птиц, даже если они вперемешку указаны в ТЗ, и в целом картина почти ни у кого не разваливается, как часто бывает в иллюстрациях к этой игре;
2) Команда с летающими коровами пошутила уже надо мной: "
несколькими коровами и птицами в небе", вот что неаккуратный союз "и" в требованиях делает!3) Заказчик не проверил заранее наличие необходимых компетенций в команде! Ну не умеют люди рисовать коров, это не проблема людей, это проблема заказчика, который не провел предварительную квалификацию участников тендера.
4) Обычно этой игрой иллюстрируют снижение креативности и полезности продукта при точном выполнении ТЗ; в целом, эффект прослеживается: есть некоторая монотонность выполнения задания по детализированному ТЗ, а также нарушение ракурса — какие-то цветы видны сбоку, какие-то сверху; какие-то огромны по сравнению с коровами, какие-то мелкие — то есть, при отсутствии указания общей цели системы возникают диспропорции и отсутствует единая точка зрения, мы через систему смотрим на мир с какой точки зрения — сверху или сбоку?.. Не понимая задачу, не построишь правильное отражение мира, хотя все отдельные элементы на месте.
5) Из всех команд только одна нашла возможность опросить заказчика (хотя я заранее говорил о такой возможности), и чаще именно работу этой команды признают наиболее подходящей с точки зрения заказчика.
Вот такое получилось забавное упражнение. С точки зрения чистоты эксперимента научности в нём нет никакой, но как иллюстрация — явно наводит на мысли 🤔
👍11❤8😁4
Когда я разбираю идеи некоторых продуктов — предлагаемых или, к сожалению, уже реализованных, — я частенько вспоминаю отрывок из книги про Винни-Пуха, когда он ловил Слонопотама:
яму приложение, а тогда ведь будет уже поздно, и там ему придётся совершить нужное нам действие -- подписаться на рассылку, совершить покупку, пройти опрос и т.п...
Почему он вообще к нам придёт и почему он будет делать то, что мы хотим — вообще обычно не анализируют. Вот прямо сейчас у меня в работе очередной проект с идеей "мы создадим ресурс с информацией по теме X, к нам придут пользователи, прочитают про X, будут обсуждать X, пройдут опросы по теме X, а мы будем их исследовать и продавать о них информацию всем, кто заинтересуется отношением общества к теме X". Чувствую себя немного Пятачком, очень хочется задать сакраментальный вопрос: — Почему он туда упадёт?
Лет 10 назад я немного соприкоснулся с темой активной социологии и краудсорсинга, и примерно представляю себе — насколько сложно мотивировать пользователя прийти, хоть что-нибудь сделать, да ещё и активно поучаствовать. Это уж должна быть такая животрепещущая тема, которая человека очень волнует, касается напрямую, и на которую он как-то может повлиять на этой платформе, или хотя бы озвучить свою позицию.
Так же обстоит дело и с другими продуктами и сервисами — никто просто так в них не упадёт и делать просто так ничего не будет, если не понимать мотивацию и цели пользователя. На этот счёт есть много техник: от простых user story и относительно простого Impact mapping, до сложных диаграмм типа Motivation Layer в Archimate. А уж теорий под этим ещё больше! И SDT (Self Determination Theory), и Behavioral Design с Behavioral Studies, и какой-нибудь Octalysis (не уверен в его эмпирических основаниях) или Bartle taxonomy of player types (которая как раз основана на массированном исследовании мотивации пользователей онлайн-игр)...
А вы используете какой-нибудь инструмент для проектирования поведения пользователей или анализа реалистичности спроектированного пути пользователя?
...Первое, что пришло Пуху в голову,— вырыть Очень Глубокую Яму, а потом Слонопотам пойдёт гулять и упадёт в эту яму, и...Мне кажется, большинство систем в части поведения пользователей спроектированы именно в такой логике: пользователь будет гулять по Интернету, мурлыкая себе под нос песенку, попадёт в нашу
— Почему? — спросил Пятачок.
— Что — почему? — сказал Пух.
— Почему он туда упадёт?
Пух потёр нос лапой и сказал, что, ну, наверно, Слонопотам будет гулять, мурлыкая себе под нос песенку и, поглядывая на небо — не пойдёт ли дождик, вот он и не заметит Очень Глубокой Ямы, пока не полетит в неё, а тогда ведь будет уже поздно.
Пятачок сказал, что это, конечно, очень хорошая Западня, но что, если дождик уже будет идти?
Пух опять почесал свой нос и сказал, что он об этом не подумал. Но тут же просиял и сказал, что, если дождь уже будет идти, Слонопотам может посмотреть на небо, чтобы узнать, скоро ли дождь перестанет, вот он опять и не заметит Очень Глубокой Ямы, пока не полетит в неё!.. А ведь тогда будет уже поздно.
Почему он вообще к нам придёт и почему он будет делать то, что мы хотим — вообще обычно не анализируют. Вот прямо сейчас у меня в работе очередной проект с идеей "мы создадим ресурс с информацией по теме X, к нам придут пользователи, прочитают про X, будут обсуждать X, пройдут опросы по теме X, а мы будем их исследовать и продавать о них информацию всем, кто заинтересуется отношением общества к теме X". Чувствую себя немного Пятачком, очень хочется задать сакраментальный вопрос: — Почему он туда упадёт?
Лет 10 назад я немного соприкоснулся с темой активной социологии и краудсорсинга, и примерно представляю себе — насколько сложно мотивировать пользователя прийти, хоть что-нибудь сделать, да ещё и активно поучаствовать. Это уж должна быть такая животрепещущая тема, которая человека очень волнует, касается напрямую, и на которую он как-то может повлиять на этой платформе, или хотя бы озвучить свою позицию.
Так же обстоит дело и с другими продуктами и сервисами — никто просто так в них не упадёт и делать просто так ничего не будет, если не понимать мотивацию и цели пользователя. На этот счёт есть много техник: от простых user story и относительно простого Impact mapping, до сложных диаграмм типа Motivation Layer в Archimate. А уж теорий под этим ещё больше! И SDT (Self Determination Theory), и Behavioral Design с Behavioral Studies, и какой-нибудь Octalysis (не уверен в его эмпирических основаниях) или Bartle taxonomy of player types (которая как раз основана на массированном исследовании мотивации пользователей онлайн-игр)...
А вы используете какой-нибудь инструмент для проектирования поведения пользователей или анализа реалистичности спроектированного пути пользователя?
👍21
Вот интересно, в очередной раз столкнулся: люди в программирование умеют, а в написание документов совсем не умеют. Не могут ни структуру документа построить, ни обеспечить логику чтения, ни проконтролировать полноту и целостность. Не знают — о чем нужно писать, о чём нет; не понимают — в какой раздел вставить информацию.
Не понимаю: я к написанию документа подхожу так же, как к проектированию системы: вот здесь у нас вот это, вот тут у нас вот то; сначала пишем об этом, потом о том. Пользователь, когда будет читать, должен получать информацию вот в таком порядке; вот это основное, вот это дополнительное, вот тут нужно сослаться на такой-то раздел, а тут оставить предупреждение.
Всё точно так же, как с системой. Но почему они могут тогда что-то запрогать, но не могут это описать?! Позвольте, а как же они тогдаслужили в очистке программируют-то?
Не понимаю: я к написанию документа подхожу так же, как к проектированию системы: вот здесь у нас вот это, вот тут у нас вот то; сначала пишем об этом, потом о том. Пользователь, когда будет читать, должен получать информацию вот в таком порядке; вот это основное, вот это дополнительное, вот тут нужно сослаться на такой-то раздел, а тут оставить предупреждение.
Всё точно так же, как с системой. Но почему они могут тогда что-то запрогать, но не могут это описать?! Позвольте, а как же они тогда
👍20🤡2
BRS, BRD, SRS, FRS, PRD, ФТ, ФЗ, ТЗ — у нас так много названий документов! Каждый раз, когда я прихожу на тренинг в новую компанию, сталкиваюсь с какими-то своими названиями.
А как у вас называются основные документы, которые вы разрабатываете?
Сталкивались ли с тем, что при переходе из одной компании в другую названия документов меняется? Остается ли при этом суть, или тоже меняется? И как во всём этом не запутаться?
А как у вас называются основные документы, которые вы разрабатываете?
Сталкивались ли с тем, что при переходе из одной компании в другую названия документов меняется? Остается ли при этом суть, или тоже меняется? И как во всём этом не запутаться?
👍10
Какая у меня складывается картина по результатам обсуждения документов, тезисно:
1. Почти у всех есть разделение на бизнес-документы и постановки задач для разработчиков.
2. Когда речь идёт о бизнес-требованиях, скорее имеются в виду "требования от бизнеса [к системе]", а не "требования к бизнесу". (Поэтому возникают такие гибриды, как "Бизнес-функциональные требования".)
3. Поэтому в документах бизнес-требований зачастую появляется уже и система, и описание процессов, т.к. уровень требований склонен "съезжать" в сторону автоматизации. При этом крайне редко используется анализ потребностей бизнеса, уточнение целеполагания (а правильную ли мы выбрали цель?), мотивации различных стейкхолдеров и анализ экономической эффективности решения. В общем, вся эта часть с анализом воздействий на бизнес и эффекта для бизнеса замыливается или вовсе не производится. Требования бизнеса фиксируются "как есть", некритически.
4. Очень редко упоминаются отдельно требования пользователей, стейкхолдеров, рынка или требования к продукту. Кажется, почти никто их отдельно не фиксирует и не анализирует. То есть, от верхнеуровневых требований бизнеса сразу же "проскакивают" к функциональным требованиям, без анализа процессов использования, целей и ожиданий пользователей. В лучшем случае этот анализ "прилипает" к документам функциональных требований.
5. Самый понятный документ — спецификация функциональных требований, причем уже в виде детальной постановки задачи. Непонятно, куда здесь девается процесс предложения и выбора альтернативных решений, видимо, он осуществляется в фоновом режиме и не фиксируется, это та самая скрытая работа по проектированию. Собственно, часто бывает, что функциональные требования фиксируются-то уже постфактум, после разработки.
В целом, кажется, что практика идёт по пути упрощения, и всё стремится к двум документам: БФТ/BRD и постановке (ТЗ/FSD). За бортом остаётся целеполагание и анализ бизнес-кейса, принятие решения о том, что цель в принципе достигается созданием какой-либо ИТ-системы; анализ и проектирование процессов использования, целей и ожиданий пользователей; выбор технических решений.
В этом смысле интересно, что системная инженерия делает акцент как раз на обратном: ConOps — это анализ бизнес-кейса, или миссии, выше уже стратегия компании; StRS — Stakeholders Requirements Specification (включая ожидания пользователей), OpsCon — операционная концепция, или концепция эксплуатации — а что с системой может происходить, штатно и нештатно, кто за это отвечает и как вообще с системой работать — извлекать пользу, сопровождать, обеспечивать ресурсами, ремонтировать, утилизировать и т.п. А уже потом — SysRS и SRS — системные требования и требования к ПО.
1. Почти у всех есть разделение на бизнес-документы и постановки задач для разработчиков.
2. Когда речь идёт о бизнес-требованиях, скорее имеются в виду "требования от бизнеса [к системе]", а не "требования к бизнесу". (Поэтому возникают такие гибриды, как "Бизнес-функциональные требования".)
3. Поэтому в документах бизнес-требований зачастую появляется уже и система, и описание процессов, т.к. уровень требований склонен "съезжать" в сторону автоматизации. При этом крайне редко используется анализ потребностей бизнеса, уточнение целеполагания (а правильную ли мы выбрали цель?), мотивации различных стейкхолдеров и анализ экономической эффективности решения. В общем, вся эта часть с анализом воздействий на бизнес и эффекта для бизнеса замыливается или вовсе не производится. Требования бизнеса фиксируются "как есть", некритически.
4. Очень редко упоминаются отдельно требования пользователей, стейкхолдеров, рынка или требования к продукту. Кажется, почти никто их отдельно не фиксирует и не анализирует. То есть, от верхнеуровневых требований бизнеса сразу же "проскакивают" к функциональным требованиям, без анализа процессов использования, целей и ожиданий пользователей. В лучшем случае этот анализ "прилипает" к документам функциональных требований.
5. Самый понятный документ — спецификация функциональных требований, причем уже в виде детальной постановки задачи. Непонятно, куда здесь девается процесс предложения и выбора альтернативных решений, видимо, он осуществляется в фоновом режиме и не фиксируется, это та самая скрытая работа по проектированию. Собственно, часто бывает, что функциональные требования фиксируются-то уже постфактум, после разработки.
В целом, кажется, что практика идёт по пути упрощения, и всё стремится к двум документам: БФТ/BRD и постановке (ТЗ/FSD). За бортом остаётся целеполагание и анализ бизнес-кейса, принятие решения о том, что цель в принципе достигается созданием какой-либо ИТ-системы; анализ и проектирование процессов использования, целей и ожиданий пользователей; выбор технических решений.
В этом смысле интересно, что системная инженерия делает акцент как раз на обратном: ConOps — это анализ бизнес-кейса, или миссии, выше уже стратегия компании; StRS — Stakeholders Requirements Specification (включая ожидания пользователей), OpsCon — операционная концепция, или концепция эксплуатации — а что с системой может происходить, штатно и нештатно, кто за это отвечает и как вообще с системой работать — извлекать пользу, сопровождать, обеспечивать ресурсами, ремонтировать, утилизировать и т.п. А уже потом — SysRS и SRS — системные требования и требования к ПО.
👍16🔥4
На канале Systems.Education опубликован мой доклад на Flow'23: https://youtu.be/HzynqWGKehQ Enjoy!
🔥13👍7
Forwarded from Системный сдвиг
Flow23-Kupriyanov.pdf
3 MB
Рассказал на Flow про скрытую работу по проектированию систем, которую выполняет системный аналитик. Хотя какая там скрытая! Вполне даже явная, в половине вакансий написано: проектировать интерфейсы пользователя, Figma; проектировать REST API, разрабатывать спецификацию в OpenAPI; знать Kafka и RabbitMQ, уметь на собеседовании объяснить разницу между AMQP и MQTT; знать SQL, уметь профилировать и оптимизировать запросы, разрабатывать физическую модель; уметь нарезать монолит на микросервисы. И аналитики такие: ЧТОА?
В общем, ловите презентацию, там есть немного ссылок по темам.
В общем, ловите презентацию, там есть немного ссылок по темам.
👍25🔥1
В нескольких обсуждениях ценности системного аналитика проскользнул аргумент "один системный аналитик обеспечивает работой 5-6 разработчиков, а то и 8", — поэтому, получается, такое разделение труда выгодно.
Я сам в таких проектах был; ну 8 — это уже как-то много, а 4-6 — легко, вполне верю. Но тут я начал у всех выяснять — а какое у них соотношение? И большинство ответов пока — 1:2, а то и 1:1‼️
Наоборот, людей удивляет, что число разработчиков может быть больше. Кажется, что если в процесс уж встроены аналитики, то их нужно прямо много. Что опровергает гипотезу об экономической выгоде чисто по соотношению ролей. Видимо, дело в чем-то другом.
А какое у вас соотношение? Сколько приходится разработчиков на одного аналитика?
Я сам в таких проектах был; ну 8 — это уже как-то много, а 4-6 — легко, вполне верю. Но тут я начал у всех выяснять — а какое у них соотношение? И большинство ответов пока — 1:2, а то и 1:1‼️
Наоборот, людей удивляет, что число разработчиков может быть больше. Кажется, что если в процесс уж встроены аналитики, то их нужно прямо много. Что опровергает гипотезу об экономической выгоде чисто по соотношению ролей. Видимо, дело в чем-то другом.
А какое у вас соотношение? Сколько приходится разработчиков на одного аналитика?
👍4
Какое в вашей компании соотношение чиса аналитиков к разработчикам?
Anonymous Poll
10%
1:1
46%
1:2-3
31%
1:4-6
13%
Больше, чем 1:6
Пост про виды документов оказался самым комментируемым за всё время ведения канала!
И, кажется, это место, где теория несколько расходится с практикой. В теории (в книгах и стандартах) нужно составлять отдельные бизнес-требования и их анализировать, чтобы принять решение — а нужна ли тут вообще ИТ-система.
На практике же это решение уже давно принято, и не в компетенции команды подвергать его сомнению. Или же система уже существует, и бизнес вообще не мыслит другого решения своих задач, кроме как через автоматизацию, то есть доработку существующих систем. Полная победа цифровизации и трансформация в бизнес-киборга. Ну, за что, собственно, и боролись.
Между тем почти все книги и стандарты у нас родом из 90-х, когда такой проблемы в принципе не было — системы в основном создавались с нуля, ну или переписывались целиком (тот же "Мифический человеко-месяц" — про переписывание системы).
А у нас сейчас в основном либо интеграция существующих систем, либо развитие существующих систем, либо надстраивание и конфигурирование коробочных решений и фреймворков (говоря языком ГОСТов — сборка и адаптация).
А эта тема так хорошо не отрефлексирована и не проработана. Не будешь же на каждую доработку расписывать полный пакет документов бизнес-уровня, да с анализом всех влияний и альтернатив! Быстрее просто сделать.
Интересная мысль, надо поискать целенаправленно именно такие книги/статьи/исследования.
И, кажется, это место, где теория несколько расходится с практикой. В теории (в книгах и стандартах) нужно составлять отдельные бизнес-требования и их анализировать, чтобы принять решение — а нужна ли тут вообще ИТ-система.
На практике же это решение уже давно принято, и не в компетенции команды подвергать его сомнению. Или же система уже существует, и бизнес вообще не мыслит другого решения своих задач, кроме как через автоматизацию, то есть доработку существующих систем. Полная победа цифровизации и трансформация в бизнес-киборга. Ну, за что, собственно, и боролись.
Между тем почти все книги и стандарты у нас родом из 90-х, когда такой проблемы в принципе не было — системы в основном создавались с нуля, ну или переписывались целиком (тот же "Мифический человеко-месяц" — про переписывание системы).
А у нас сейчас в основном либо интеграция существующих систем, либо развитие существующих систем, либо надстраивание и конфигурирование коробочных решений и фреймворков (говоря языком ГОСТов — сборка и адаптация).
А эта тема так хорошо не отрефлексирована и не проработана. Не будешь же на каждую доработку расписывать полный пакет документов бизнес-уровня, да с анализом всех влияний и альтернатив! Быстрее просто сделать.
Интересная мысль, надо поискать целенаправленно именно такие книги/статьи/исследования.
👍31❤4🔥1
На прошлой неделе был на конференции Infostart Tech Event. Это одна из крупнейших конференции по 1С. Сообщество 1С сейчас развивается с потрясающей скоростью, там много интересного. Но меня в основном интересовали доклады, не относящиеся напрямую к технологии, а рассказывающие про процессы и организацию работы. Посмотреть удалось не очень много, но вот что я для себя отметил:
1. Удивительно ёмкий доклад Павла Алферова про кризисные проекты. Я вообще не очень люблю рассказы про проектное управление, потому что, во-первых, работа над ИТ-продуктами это не проектная деятельность (а если её подгоняют про проект, то это зачастую ведёт к нехорошим последствиям); а, во-вторых, очень часто проектные ребята совершенно не учитывают содержание проекта и особенности выполнения работ.
Но мимо темы кризисных проектов я не мог пройти — я в принципе много работаю с кризисными проектами.
И тут Павел меня приятно порадовал. Начал он с исследований Standish Group — Chaos Report — с перспективой от 1994 до 2018 годов. Там 46% всех проектов challenged (то есть, были реализованы с отклонениями от начальных сроков, бюджетов или объемов), 19% вообще не были выполнены (это в 2018, в 1994 проваливались 35% проектов). Тут у меня сразу возник вопрос про обусловленность такого успеха — Standish это объясняет распространением практик Agile☝🏻.
Дальше вводится типология кризисных проектов: 1) в которых всё шло хорошо — то есть, проектные усилия были адекватны внешним условиям, но потом случилось что-то катастрофическое и внешние условия резко изменились; 2) в которых проектные усилия мееедленно расходились с внешней средой, и в какой-то момент стало уже поздно; 3) в которых проектные усилия никогда и не находились в соответствии с внешней средой (то есть, изначально обреченные проекты).
Был пример проекта внедрения 1С, в котором по отдельности все подсистемы работали, а вместе никак не соединялись, и вариантов выхода из него. Вариант, на удивление, был "перешли на работу по scrum", кто бы мог подумать-то, а! Про варианты спрашивали у зрителей, предлагая разные варианты действий. База таких вариантов и инструментов есть у автора. (прямо набор практик, как в OMG Essence!)
Проект, естественно, был из разряда "вроде всё шло хорошо, а потом оказалось, что ж*па". И дальше было обсуждение — а как же это на ранних стадиях выявить. Тут интересны две вещи: во-первых, пока заказчик проекта не осознает расхождение между проектными усилиями и внешней средой — бесполезно с ним разговаривать, не поймёт. В примере — если бы заказчику сразу предложили работать по scrum, он бы не согласился: вы же взяли на себя обязательства, ну вот и делайте, зачем ещё мне с вами каждую неделю встречаться и работу вашу проверять?! Дел других нет. То есть, признание руководства, о котором во всех проектных гайдах пишут, это ещё и признание, что проект находится в кризисе, и уже нужно что-то делать. Во-вторых, нужна система контрольных точек (сформулированных в форме объективно наблюдаемого и проверяемого состояния мира), и — вот это новое! — регулярный опрос ключевых вовлеченных в проект лиц по их оценке вероятности достижения следующих контрольных точек в срок. Ну просто как светофор: насколько вы уверены, что в такой-то срок доедем до такой-то точки? Верю, сомневаюсь, совсем не верю. И если будущие точки начали краснеть — это признак подбирающегося кризиса. Более детально метод описан здесь. Инструмент выглядит очень здраво, я сам таким светофором пользовался в одном из проектов ещё лет 15 назад (правда, не задумался тогда, что это что-то необычное и стоит про это рассказывать на конференциях).
1. Удивительно ёмкий доклад Павла Алферова про кризисные проекты. Я вообще не очень люблю рассказы про проектное управление, потому что, во-первых, работа над ИТ-продуктами это не проектная деятельность (а если её подгоняют про проект, то это зачастую ведёт к нехорошим последствиям); а, во-вторых, очень часто проектные ребята совершенно не учитывают содержание проекта и особенности выполнения работ.
Но мимо темы кризисных проектов я не мог пройти — я в принципе много работаю с кризисными проектами.
И тут Павел меня приятно порадовал. Начал он с исследований Standish Group — Chaos Report — с перспективой от 1994 до 2018 годов. Там 46% всех проектов challenged (то есть, были реализованы с отклонениями от начальных сроков, бюджетов или объемов), 19% вообще не были выполнены (это в 2018, в 1994 проваливались 35% проектов). Тут у меня сразу возник вопрос про обусловленность такого успеха — Standish это объясняет распространением практик Agile☝🏻.
Дальше вводится типология кризисных проектов: 1) в которых всё шло хорошо — то есть, проектные усилия были адекватны внешним условиям, но потом случилось что-то катастрофическое и внешние условия резко изменились; 2) в которых проектные усилия мееедленно расходились с внешней средой, и в какой-то момент стало уже поздно; 3) в которых проектные усилия никогда и не находились в соответствии с внешней средой (то есть, изначально обреченные проекты).
Был пример проекта внедрения 1С, в котором по отдельности все подсистемы работали, а вместе никак не соединялись, и вариантов выхода из него. Вариант, на удивление, был "перешли на работу по scrum", кто бы мог подумать-то, а! Про варианты спрашивали у зрителей, предлагая разные варианты действий. База таких вариантов и инструментов есть у автора. (прямо набор практик, как в OMG Essence!)
Проект, естественно, был из разряда "вроде всё шло хорошо, а потом оказалось, что ж*па". И дальше было обсуждение — а как же это на ранних стадиях выявить. Тут интересны две вещи: во-первых, пока заказчик проекта не осознает расхождение между проектными усилиями и внешней средой — бесполезно с ним разговаривать, не поймёт. В примере — если бы заказчику сразу предложили работать по scrum, он бы не согласился: вы же взяли на себя обязательства, ну вот и делайте, зачем ещё мне с вами каждую неделю встречаться и работу вашу проверять?! Дел других нет. То есть, признание руководства, о котором во всех проектных гайдах пишут, это ещё и признание, что проект находится в кризисе, и уже нужно что-то делать. Во-вторых, нужна система контрольных точек (сформулированных в форме объективно наблюдаемого и проверяемого состояния мира), и — вот это новое! — регулярный опрос ключевых вовлеченных в проект лиц по их оценке вероятности достижения следующих контрольных точек в срок. Ну просто как светофор: насколько вы уверены, что в такой-то срок доедем до такой-то точки? Верю, сомневаюсь, совсем не верю. И если будущие точки начали краснеть — это признак подбирающегося кризиса. Более детально метод описан здесь. Инструмент выглядит очень здраво, я сам таким светофором пользовался в одном из проектов ещё лет 15 назад (правда, не задумался тогда, что это что-то необычное и стоит про это рассказывать на конференциях).
👍8🔥2👏1
В обсуждении не мог удержаться, чтобы не спросить -- раз всё в итоге к agile сводится, почему бы сразу с него не начать?
Тут мнение докладчика таково, что не всегда можно сразу "продать" agile (ну да, заказчик сначала настроен оптимистично и не хочет сильно вкладываться), и что не всем проектам agile подходит, а вот есть радар выбора подходов к управлению проектами от PMI. Ну, я заодно нашел отличный сайт с картинками: https://www.pmillustrated.com/2-13-determine-project-approach/ , там есть картинка про выбор подхода, на основе трех областей и 9 показателей:
✅ команда (компактность, опыт, доступность клиентов/пользователей),
✅ проект (вероятность изменений первоначальных требований, безопасность проекта, возможность частичной поставки),
✅ культура (готовность заказчика к agile, доверие между стейкхолдерами и командой, готовность заказчика передать часть решений команде).
В зависимости ответов на эти вопросы строится "паутинка" - и по её виду можно понять, какой подход вам более подойдёт -- agile, плановый, или гибридный. Сам автор как раз предлагает на впадать в крайности и ориентироваться на гибридные подходы, но это уже за рамками доклада.
Тут мнение докладчика таково, что не всегда можно сразу "продать" agile (ну да, заказчик сначала настроен оптимистично и не хочет сильно вкладываться), и что не всем проектам agile подходит, а вот есть радар выбора подходов к управлению проектами от PMI. Ну, я заодно нашел отличный сайт с картинками: https://www.pmillustrated.com/2-13-determine-project-approach/ , там есть картинка про выбор подхода, на основе трех областей и 9 показателей:
✅ команда (компактность, опыт, доступность клиентов/пользователей),
✅ проект (вероятность изменений первоначальных требований, безопасность проекта, возможность частичной поставки),
✅ культура (готовность заказчика к agile, доверие между стейкхолдерами и командой, готовность заказчика передать часть решений команде).
В зависимости ответов на эти вопросы строится "паутинка" - и по её виду можно понять, какой подход вам более подойдёт -- agile, плановый, или гибридный. Сам автор как раз предлагает на впадать в крайности и ориентироваться на гибридные подходы, но это уже за рамками доклада.
PM Illustrated - A Visual Learners Guide to Project Management
2.13 Determine Appropriate Project Methodology/Methods and Practices - PM Illustrated PMP Exam
No Single Best Approach There is no specific, best way of executing every project. If there were, it would likely have been automated by now and project managers made obsolete. However, because all projects are different (even building the same house in a…
👍5🔥3
2. Доклад Евгения Мазуренко из Ozon Tech "Как управлять проектами и не терять связь с заказчиком". Рассказ про устройство процесса, люблю такое.
У них это сделано так: на каждый домен (почти продукт, но это внутренняя разработка; в общем — то, что решает определенный набор задач бизнеса) имеется технический комитет, собранный из представителей бизнес-заказчиков. ИТ-шники тоже в нём участвуют, но в роли наблюдателей и консультантов. А вот представители заказчиков между собой определяют приоритеты задач, предварительно оцененных разработкой. То есть, задачи могут прилетать от разных заказчиков, но всё равно все рассматриваются через техком, и никак иначе в работу не попадают. Для рассмотрения на техкоме задачи оцениваются по значимости — по системе влияния на метрики с весами метрик. Каждый техком формирует набор таких метрик самостоятельно, силами представителей заказчиков. Метрики стараются приводить к деньгам. Чтобы уровнять фичи с коротким сроком окупаемости и с длинным, берут оценку денег в расчете на 3 года.
Сложность задач команда оценивает в "майках" — от XS до XXXL, которым соответствуют человеко-дни. Задачи размера XS на техкоме не приоритизируются, просто берутся в работу, когда есть окно. Кроме того, у команды есть зарезервированное время на погашение техдолга и на поддержку. Фичи, рассмотренные на техкоме, то есть проекты, связываются с задачами в Jira. Сами заказчики в Jira не ходят, отслеживают записи техкомов, для этого есть специальный софт. В этом софте видны статусы всех проектов. Разработчики должны обновлять статус проекта каждые две недели. Если ничего не изменилось -- пишут, почему ничего не изменилось (например, более срочные задачи или ждут другой домен). Так бизнес всегда в курсе, что происходит.
Теперь самое интересное: где тут аналитики (это я потом в кулуарах спрашивал, в докладе этого нет). А аналитики тут в самом начале! То есть, приходит заказчик с запросом, и аналитик прорабатывает этот запрос до такого состояния, чтобы команда могла его оценить. Если техком собирается раз в две недели, у аналитиков есть две недели на то, чтобы разобраться с новыми запросами. Число аналитиков разное в зависимости от домена, но их много, 1/2-1/3.
В общем, процесс выглядит очень разумно. Записей докладов с Infostart Tech Event пока нет, но я нашел запись того же доклада с недавнего митапа: https://www.youtube.com/watch?v=E7mOy2vr2hc&t=1080s
У них это сделано так: на каждый домен (почти продукт, но это внутренняя разработка; в общем — то, что решает определенный набор задач бизнеса) имеется технический комитет, собранный из представителей бизнес-заказчиков. ИТ-шники тоже в нём участвуют, но в роли наблюдателей и консультантов. А вот представители заказчиков между собой определяют приоритеты задач, предварительно оцененных разработкой. То есть, задачи могут прилетать от разных заказчиков, но всё равно все рассматриваются через техком, и никак иначе в работу не попадают. Для рассмотрения на техкоме задачи оцениваются по значимости — по системе влияния на метрики с весами метрик. Каждый техком формирует набор таких метрик самостоятельно, силами представителей заказчиков. Метрики стараются приводить к деньгам. Чтобы уровнять фичи с коротким сроком окупаемости и с длинным, берут оценку денег в расчете на 3 года.
Сложность задач команда оценивает в "майках" — от XS до XXXL, которым соответствуют человеко-дни. Задачи размера XS на техкоме не приоритизируются, просто берутся в работу, когда есть окно. Кроме того, у команды есть зарезервированное время на погашение техдолга и на поддержку. Фичи, рассмотренные на техкоме, то есть проекты, связываются с задачами в Jira. Сами заказчики в Jira не ходят, отслеживают записи техкомов, для этого есть специальный софт. В этом софте видны статусы всех проектов. Разработчики должны обновлять статус проекта каждые две недели. Если ничего не изменилось -- пишут, почему ничего не изменилось (например, более срочные задачи или ждут другой домен). Так бизнес всегда в курсе, что происходит.
Теперь самое интересное: где тут аналитики (это я потом в кулуарах спрашивал, в докладе этого нет). А аналитики тут в самом начале! То есть, приходит заказчик с запросом, и аналитик прорабатывает этот запрос до такого состояния, чтобы команда могла его оценить. Если техком собирается раз в две недели, у аналитиков есть две недели на то, чтобы разобраться с новыми запросами. Число аналитиков разное в зависимости от домена, но их много, 1/2-1/3.
В общем, процесс выглядит очень разумно. Записей докладов с Infostart Tech Event пока нет, но я нашел запись того же доклада с недавнего митапа: https://www.youtube.com/watch?v=E7mOy2vr2hc&t=1080s
👍15❤3🤩2
Есть такое модное понятие, применительно к медиа —фактчекинг. То есть, поиск и проверка источников. У аналитика это должно срабатывать на уровне рефлекса: кто-то сказал — нужно проверить и найти подтверждение, что это действительно так. Особенно интересно бывает найти нормативный документ, и увидеть, что практика с ним серьёзно расходится.
И у меня этот рефлекс часто срабатывает в обычной жизни. Иногда находится прекрасное.
Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно:
"Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%."
Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать.
Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг.
То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.
И у меня этот рефлекс часто срабатывает в обычной жизни. Иногда находится прекрасное.
Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно:
"Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%."
Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать.
Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг.
То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.
😁44❤10🔥5
Немного об интеграциях:
— У нас на проекте Кафка.
— Для маршрутизации сообщений?
— ...
— Для маршрутизации сообщений, верно ведь?..
— У нас на проекте Кафка.
— Для маршрутизации сообщений?
— ...
— Для маршрутизации сообщений, верно ведь?..
😁25❤6
Хороших каналов по системному анализу становится всё больше, и сегодня хочу вас познакомить с каналом, который так и называется: Системный аналитик. Там множество материалов по нашей теме, вот только небольшая подборка:
👍2
🔥 Подборка материалов от телеграм-канала Системный Аналитик
📚 20 лучших книг для развития аналитика — можно скачать бесплатно
📨 Брокеры сообщений: Kafka и RabbitMQ, сравнение Kafka vs Rabbit
🏭 PlantUML с нуля
📌 Подброка бесплатных материалов базам данных и SQL
▶️ Подборка бесплатных вебинаров по основам интеграции систем
📎 Подборка материалов по изучению REST
🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений
🌐 HTTP. Что нужно знать аналитику
⚙️ Интеграция через API. Кратко
🤓 Задачник для системных аналитиков от Тинькофф
🧿 Виртуализация, контейнеризация и оркестрация
💪 Карта навыков системного аналитика
🧮 Про нефункциональные требования
🆚 Сравнение REST vs SOAP, gRPC vs REST, GraphQL vs REST
📚 20 лучших книг для развития аналитика — можно скачать бесплатно
📨 Брокеры сообщений: Kafka и RabbitMQ, сравнение Kafka vs Rabbit
🏭 PlantUML с нуля
📌 Подброка бесплатных материалов базам данных и SQL
▶️ Подборка бесплатных вебинаров по основам интеграции систем
📎 Подборка материалов по изучению REST
🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений
🌐 HTTP. Что нужно знать аналитику
⚙️ Интеграция через API. Кратко
🤓 Задачник для системных аналитиков от Тинькофф
🧿 Виртуализация, контейнеризация и оркестрация
💪 Карта навыков системного аналитика
🧮 Про нефункциональные требования
🆚 Сравнение REST vs SOAP, gRPC vs REST, GraphQL vs REST
Telegram
Системный Аналитик
Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни.
Реклама и сотрудничество @radale
https://gosuslugi.ru/snet/67b0613c6411ff785396754a
Реклама и сотрудничество @radale
https://gosuslugi.ru/snet/67b0613c6411ff785396754a
🔥16👍4❤2
В пятницу побыл в непривычной для себя роли — ведущего круглого стола. В гостях у Самоката обсуждали требования к роли системного аналитика, грейды, матрицы компетенций и возможный рост. Получилось интересно и содержательно!
И уже есть запись: https://www.youtube.com/live/uRQuVT1xxMY?si=Xfnojsa0GGl05kHx
Вначале там выступление Анастасии Тарасовой из Самоката про аналитика как координатора кросс-доменных проектов, потом Жени Скорикова из AWG про подход к разработке нефункциональных требований (что бессмысленно просто давать какие-то значения доступности или надежности, а нужно предлагать бизнесу баланс значений и затрат на их обеспечение — ну, там у Жени целая методика).
А потом, с 2:18:50 — наш круглый стол.
И уже есть запись: https://www.youtube.com/live/uRQuVT1xxMY?si=Xfnojsa0GGl05kHx
Вначале там выступление Анастасии Тарасовой из Самоката про аналитика как координатора кросс-доменных проектов, потом Жени Скорикова из AWG про подход к разработке нефункциональных требований (что бессмысленно просто давать какие-то значения доступности или надежности, а нужно предлагать бизнесу баланс значений и затрат на их обеспечение — ну, там у Жени целая методика).
А потом, с 2:18:50 — наш круглый стол.
Youtube
- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
🔥18👍1
Сформулировал в одной дискуссии положения про метрики API:
1⃣ Есть три уровня метрик: инфраструктурные (что с железом и каналами) , прикладные (что с запросами и ответами, токенами и т.д)
и продуктовые/бизнесовые (что с качеством данных, бизнес-процессами, клиентами).
2⃣ С точки зрения измерений, что меряем:
- производительность/ресурсы (CPU/память/IO/сеть), RPS;
- скорость/задержки (latency: среднее, максимальное, 95 перцентиль, 99 перцентиль),
- число ошибок (4xx, 5xx);
- консистентность ответов (соответствие структуры, полнота, отсутствие дублей, соответствие размера/распределения ответа ожидаемому).
Если есть кеш — число попаданий/промахов.
Если есть требования к безопасности — число [неудачных] попыток авторизации, ошибки шифрования, ошибки сертификата, число выданных токенов;
Если есть есть требования по гарантированной доставке — число перепосылок, счетчики успешных/неуспешных перепосылок.
Соответственно, настраиваем мониторинг и алерты этих показателей на выход за установленные пределы или на приближение к пределам (например, при определенном числе фейлов перепосылок за какое-то время).
Вот неплохая статья про метрики открытого API: https://www.moesif.com/blog/technical/api-metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/
А вот ещё одна, более техническая: https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring (не смотрите, что про Azure, там метрики универсальные).
1⃣ Есть три уровня метрик: инфраструктурные (что с железом и каналами) , прикладные (что с запросами и ответами, токенами и т.д)
и продуктовые/бизнесовые (что с качеством данных, бизнес-процессами, клиентами).
2⃣ С точки зрения измерений, что меряем:
- производительность/ресурсы (CPU/память/IO/сеть), RPS;
- скорость/задержки (latency: среднее, максимальное, 95 перцентиль, 99 перцентиль),
- число ошибок (4xx, 5xx);
- консистентность ответов (соответствие структуры, полнота, отсутствие дублей, соответствие размера/распределения ответа ожидаемому).
Если есть кеш — число попаданий/промахов.
Если есть требования к безопасности — число [неудачных] попыток авторизации, ошибки шифрования, ошибки сертификата, число выданных токенов;
Если есть есть требования по гарантированной доставке — число перепосылок, счетчики успешных/неуспешных перепосылок.
Соответственно, настраиваем мониторинг и алерты этих показателей на выход за установленные пределы или на приближение к пределам (например, при определенном числе фейлов перепосылок за какое-то время).
Вот неплохая статья про метрики открытого API: https://www.moesif.com/blog/technical/api-metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/
А вот ещё одна, более техническая: https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring (не смотрите, что про Azure, там метрики универсальные).
13 API Metrics That Every Platform Team Should be Tracking | Moesif Blog
13 API Metrics That Every Platform Team Should be Tracking
A list of the most important API metrics every API product manager and engineer should know, especially when you are looking into API Analytics and Monitoring.
👍20❤3🔥2