В обсуждении списывания времени проскочило совсем дикое сообщение, что в некоторых компаниях запрещают списывать время на совещания и созвоны. Как при этом набрать 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
Никто не может объять необъятное. Сколько не изучай методы проектирования API, всегда найдется что-то новое. Или старое. Вот, например, текст, который мне раньше не попадался, и идеи, которые в нём приводятся, тоже отдельно не встречались (хотя сам я их использовал при проектировании, так часто бывает).
Статья 2014 года, нужно это иметь в виду! В некоторых местах взгляды автора явно несколько устарели.
Итак, Майк Амундсен, Методология проектирования API из 7 шагов, краткий пересказ:
Хороший дизайн идёт прежде эндпоинтов, кодов ответов, заголовков и форматов сообщений.
1️⃣ Перечислите все данные, которые клиентское приложение может захотеть получить или передать в сервис. Назовем их семантическими дескрипторами — они имеют смысл и описывают, что происходит в приложении. Важно: это точка зрения именно клиента! Примеры для приложения для ведения списка дел:
id: уникальный идентификатор каждой записи в системе;
noscript: название каждого пункта;
dateDue: дата, до которой нужно сделать дело;
complete: флаг да/нет, показывающий, сделано ли дело.
(на курсе мы называем это "словарь данных")
2️⃣ Нарисуйте диаграмму состояний
Тут автор приводит некую хитрую диаграмму, где прямоугольниками нарисованы формы представления (representations) — документы или экраны, содержащие элементы данных (семантические дескрипторы из предыдущего шага). Между формами представления рисуют стрелки — переходы. То есть, каждый переход трансформирует форму представления (например, список дел➡️ одно дело). Трансформации помечаются как безопасные (идемпотентные) или небезопасные (неидемпотентные). Названия переходов-трансформаций — это тоже семантические дескрипторы.
3️⃣ Согласуйте "магические имена"
"Магические имена" — это названия ваших семнатических дескрипторов. Майк рекомендует придумывать их не абы как, а синхронизировать с открытыми перечнями названий данных и операций: schema.org, microformats.org, Dublin Core, IANA Link Relation Values. Идея в том, что с этими именами разработчики клиентов могли ранее сталкиваться в других API, и поймут их смысл. Для своего примера он выбирает такие названия:
id -> identifier из Dublin Core;
noscript -> name из Schema.org;
dueDate -> scheduledTime (мне кажется, dueDate было понятнее)
complete -> status (вот тут я против, скажу прямо)
(В общем, спорное решение, но вообще над стандартизацией названий и действий стоит задуматься!)
4️⃣ Выберите Media Type
Тут можно выбирать между XML/HTML/JSON/и т.д., но можно и глубже — например, структуры JSON могут быть разными (скажем, есть HAL, а есть JSON:API, это всё зарегистрированные IANA медиа-типы).
5️⃣ Создайте "семантический профиль"
Тут всё просто — это OpenAPI или TypeSpec (автор упоминает WSDL, я немного актуализировал).
6️⃣ Напишите или сгенерируйте серверный и клиентский код.
7️⃣ Опубликуйте описание API в каталоге
(Имеется в виду, что он есть у вас в организации или вы публикуете спецификацию открытого API в одном из общедоступных каталогов).
Вот такие шаги :)
С одной стороны, сейчас звучит немного наивно, с другой — если задуматься, то часто ли мы делаем эти шаги и вообще задумываемся об этих вещах? Нам бы с эндпоинтами и кодами ошибок разобраться...
Статья 2014 года, нужно это иметь в виду! В некоторых местах взгляды автора явно несколько устарели.
Итак, Майк Амундсен, Методология проектирования API из 7 шагов, краткий пересказ:
Хороший дизайн идёт прежде эндпоинтов, кодов ответов, заголовков и форматов сообщений.
id: уникальный идентификатор каждой записи в системе;
noscript: название каждого пункта;
dateDue: дата, до которой нужно сделать дело;
complete: флаг да/нет, показывающий, сделано ли дело.
(на курсе мы называем это "словарь данных")
Тут автор приводит некую хитрую диаграмму, где прямоугольниками нарисованы формы представления (representations) — документы или экраны, содержащие элементы данных (семантические дескрипторы из предыдущего шага). Между формами представления рисуют стрелки — переходы. То есть, каждый переход трансформирует форму представления (например, список дел
"Магические имена" — это названия ваших семнатических дескрипторов. Майк рекомендует придумывать их не абы как, а синхронизировать с открытыми перечнями названий данных и операций: schema.org, microformats.org, Dublin Core, IANA Link Relation Values. Идея в том, что с этими именами разработчики клиентов могли ранее сталкиваться в других API, и поймут их смысл. Для своего примера он выбирает такие названия:
id -> identifier из Dublin Core;
noscript -> name из Schema.org;
dueDate -> scheduledTime (мне кажется, dueDate было понятнее)
complete -> status (вот тут я против, скажу прямо)
(В общем, спорное решение, но вообще над стандартизацией названий и действий стоит задуматься!)
Тут можно выбирать между XML/HTML/JSON/и т.д., но можно и глубже — например, структуры JSON могут быть разными (скажем, есть HAL, а есть JSON:API, это всё зарегистрированные IANA медиа-типы).
Тут всё просто — это OpenAPI или TypeSpec (автор упоминает WSDL, я немного актуализировал).
(Имеется в виду, что он есть у вас в организации или вы публикуете спецификацию открытого API в одном из общедоступных каталогов).
Вот такие шаги :)
С одной стороны, сейчас звучит немного наивно, с другой — если задуматься, то часто ли мы делаем эти шаги и вообще задумываемся об этих вещах? Нам бы с эндпоинтами и кодами ошибок разобраться...
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20👍3
Стартовал образовательный сезон — даже не знаю, какой по счёту — 17?.. Кажется, я начал регулярно преподавать в 2007 году, разработал и вел курс "Технологии программирования" в МИЭМе. До этого никто и никогда не рассказывал студентам про паттерны, VCS и таск-трекеры, представляете?
Стартую бодро, с корпоративного курса по проектированию интеграций, группа подобралась отличная!
Сразу после курса еду на Flow 2024 Autumn — рассказывать о результатах исследования по использованию диаграмм.
В октябре будет открытый тренинг по системному анализу и разработке требований — пройдем в деталях весь путь от первоначальной задумки до готового ТЗ. Подойдет тем, кто хочет систематизировать знания в системном анализе и овладеть основными техниками — отзывам, курс очень хорошо собирает в единую картину разрозненные знания, если вы осваивали системный анализ по книгам и самостоятельно.
В ноябре опять открытый очный курс в Москве, но уже по основам проектирования интеграций. В каком-то смысле — развитие и продолжение тренинга по разработке требований, но теперь у вас не одна система, а интегрированный комплекс.
Потом, вероятно, будет Analyst Days, ну и между этим всем ещё наверняка парочку корпоративных воткнут.
Сезон! Все хотят учиться! (Если вы тоже хотите — приходите в личку за промокодами)
Стартую бодро, с корпоративного курса по проектированию интеграций, группа подобралась отличная!
Сразу после курса еду на Flow 2024 Autumn — рассказывать о результатах исследования по использованию диаграмм.
В октябре будет открытый тренинг по системному анализу и разработке требований — пройдем в деталях весь путь от первоначальной задумки до готового ТЗ. Подойдет тем, кто хочет систематизировать знания в системном анализе и овладеть основными техниками — отзывам, курс очень хорошо собирает в единую картину разрозненные знания, если вы осваивали системный анализ по книгам и самостоятельно.
В ноябре опять открытый очный курс в Москве, но уже по основам проектирования интеграций. В каком-то смысле — развитие и продолжение тренинга по разработке требований, но теперь у вас не одна система, а интегрированный комплекс.
Потом, вероятно, будет Analyst Days, ну и между этим всем ещё наверняка парочку корпоративных воткнут.
Сезон! Все хотят учиться! (Если вы тоже хотите — приходите в личку за промокодами)
👍8🔥4❤2
На тренинге возник вопрос: вот я аналитик/менеджер/заказчик. Разработчики или архитекторы приносят проект архитектуры. Как мне понять — он хороший или нет? Соответствует ли он требованиям бизнеса? Подойдет ли? Не будет ли с такой архитектурой проблем в дальнейшем, а если будут — то в каком месте они могут возникнуть? И как вообще разработчики и архитекторы придумывают эту архитектуру? Что бы почитать или какой курс пройти на эту тему?
Мне, в первую очередь, приходит в голову книга Алекса Сюя про прохождение System Design Interview. Но для совсем начинающих там очень хороша первая глава ("Масштабирование от 0 до миллионов пользователей"), а дальше начинаются частности — примеры рассуждений при проектировании конкретных систем, причем зачастую низкоуровневых: ограничителя трафика, хранилища ключ-значение, генератора уникальных идентификаторов и т.п. Нет, там есть, конечно, проектирование новостной ленты, мессенджера, youtube и google drive, что можно соотнести с прикладными задачами, но половина примеров — чисто инфраструктурные, и тут, мне кажется, разрыв с первой вводной главой слишком велик — нужно предварительное понимание, например, как работает кэш, а это и не каждый программист понимает.
Первая глава последовательно вводит некоторые базовые идеи, рассказывающие о начальных принципах архитектуры:
* система с одним сервером (имеется в виду веб или мобильное приложение с бэкендом);
* выделение базы данных (и короткий обзор реляционных и NoSQL);
* вертикальное и горизонтальное масштабирование;
* балансировщики нагрузки;
* репликация;
* кэширование;
* системы с сохранением состояния и без сохранения состояния;
* очереди сообщений и т.д.
А вот более сложные концепции, типа CAP-теоремы, технологий опроса (polling, long polling, WebSocket...), стратегии гарантированной доставки или примеры решений по обработке ошибок — "зарыты" в описании конкретных примеров. Причем заранее не угадаешь — где будет про проектирование API (тема подходит для технического менеджера или аналитика), а где про префиксные деревья (тема чисто программистская).
Кроме того, почти во всех решениях у Сюя акцент ставится на масштабируемости, миллионах и миллиардах пользователей, а в наших задачах ведущей характеристикой может быть совсем другое — стоимость решения или его надежность.
К сожалению, я не знаю хорошей книги или курса, где были бы одновременно описаны основные концепции, важные для архитектурного проектирования, и на таком уровне, чтобы не приходилось впиливаться в глубины алгоритмов. Если встречали такое — дайте мне знать.
Мне, в первую очередь, приходит в голову книга Алекса Сюя про прохождение System Design Interview. Но для совсем начинающих там очень хороша первая глава ("Масштабирование от 0 до миллионов пользователей"), а дальше начинаются частности — примеры рассуждений при проектировании конкретных систем, причем зачастую низкоуровневых: ограничителя трафика, хранилища ключ-значение, генератора уникальных идентификаторов и т.п. Нет, там есть, конечно, проектирование новостной ленты, мессенджера, youtube и google drive, что можно соотнести с прикладными задачами, но половина примеров — чисто инфраструктурные, и тут, мне кажется, разрыв с первой вводной главой слишком велик — нужно предварительное понимание, например, как работает кэш, а это и не каждый программист понимает.
Первая глава последовательно вводит некоторые базовые идеи, рассказывающие о начальных принципах архитектуры:
* система с одним сервером (имеется в виду веб или мобильное приложение с бэкендом);
* выделение базы данных (и короткий обзор реляционных и NoSQL);
* вертикальное и горизонтальное масштабирование;
* балансировщики нагрузки;
* репликация;
* кэширование;
* системы с сохранением состояния и без сохранения состояния;
* очереди сообщений и т.д.
А вот более сложные концепции, типа CAP-теоремы, технологий опроса (polling, long polling, WebSocket...), стратегии гарантированной доставки или примеры решений по обработке ошибок — "зарыты" в описании конкретных примеров. Причем заранее не угадаешь — где будет про проектирование API (тема подходит для технического менеджера или аналитика), а где про префиксные деревья (тема чисто программистская).
Кроме того, почти во всех решениях у Сюя акцент ставится на масштабируемости, миллионах и миллиардах пользователей, а в наших задачах ведущей характеристикой может быть совсем другое — стоимость решения или его надежность.
К сожалению, я не знаю хорошей книги или курса, где были бы одновременно описаны основные концепции, важные для архитектурного проектирования, и на таком уровне, чтобы не приходилось впиливаться в глубины алгоритмов. Если встречали такое — дайте мне знать.
❤20👍7
Мы с уточкой передаем всем подписчикам большой привет с конференции Flow'2024, поздравляем с днём системного аналитика, и желаем удачных проектов, интересных задач, успешного профессионального развития, достижения личных и карьерных целей, а также всеобщего процветания!
Ура!🎆 🎆 🎆
Ура!
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤42🍾19
Ладно, а теперь серьёзно: второй день Flow начинается с двух докладов, в которых есть кое-что общее. Один — рассказ Дениса Котова про метод разработки BPMN. Так и называется: "BPMN — стандарт, но все всё равно рисуют ерунду. Что делать?". Проблема в том, что BPMN — стандарт графической нотации. Что может быть и что не может быть нарисовано. Но как выявлять процесс и его шаги — об этом BPMN не говорит. Не задаёт методику работы.
Второй — интерактивный и провокационный — доклад Сергея Нужненко "Как аналитику подняться от уровня «ноги с ушами» и стать инженером". Сергей показывает задачки с собеседований, вроде бы несложные, но на них срезается половина аналитиков. А чтобы не срезаться — вспоминает методы структурного анализа, откуда к нам пришли IDEF0 и DFD, и которые являются именно методами, то есть инструкциями, как действовать, какие шаги выполнять и как результаты предыдущего шага трансформировать на следующем шаге.
В этом проблема: если мы возьмем те же UML или BPMN, это будут просто нотации. В случае UML "Три амиго" объединились для унификации нотации: какие графические элементы что означают, какие виды диаграмм имеет смысл выделить. Но они не договорились (и не собирались!) про метод их создания — с каких диаграмм нужно начинать, и какие вообще использовать. Метод у каждого был свой — у Буча имени Буча; у Рамбо — Object-Modeling Technique, OMT; у Якобсона — Objectory или OOSE (кстати, только в нём была Use Case Diagram). UML задумывался как нотация, которая поддерживает любую методологию — хоть одну из начальных, хоть какую-то новую.
На практике произошло вот что: UML все начали использовать, но методологий никаких изучать не стали.
То же касается интеграций: все уже знают, какими свойствами обладают разные технологии интеграций, и даже изучили OpenAPI и Swagger, но мало у кого есть метод проектирования API.
Отсюда часто возникает вопрос: вот я прочитал много книг и статей про UML, юскейсы, API — но не понимаю, как всё это связать? Когда использовать одно, когда другое? В голове какая-то каша.
А нужен метод работы! Или, по руководству INCOSE, набор формальных преобразований. Здесь мы с ними сходимся: если вы в принципе готовы рассматривать идею "требований", как отдельно существующих вещей, то эти требования обязаны быть результатом формальных преобразований:
Второй — интерактивный и провокационный — доклад Сергея Нужненко "Как аналитику подняться от уровня «ноги с ушами» и стать инженером". Сергей показывает задачки с собеседований, вроде бы несложные, но на них срезается половина аналитиков. А чтобы не срезаться — вспоминает методы структурного анализа, откуда к нам пришли IDEF0 и DFD, и которые являются именно методами, то есть инструкциями, как действовать, какие шаги выполнять и как результаты предыдущего шага трансформировать на следующем шаге.
В этом проблема: если мы возьмем те же UML или BPMN, это будут просто нотации. В случае UML "Три амиго" объединились для унификации нотации: какие графические элементы что означают, какие виды диаграмм имеет смысл выделить. Но они не договорились (и не собирались!) про метод их создания — с каких диаграмм нужно начинать, и какие вообще использовать. Метод у каждого был свой — у Буча имени Буча; у Рамбо — Object-Modeling Technique, OMT; у Якобсона — Objectory или OOSE (кстати, только в нём была Use Case Diagram). UML задумывался как нотация, которая поддерживает любую методологию — хоть одну из начальных, хоть какую-то новую.
На практике произошло вот что: UML все начали использовать, но методологий никаких изучать не стали.
То же касается интеграций: все уже знают, какими свойствами обладают разные технологии интеграций, и даже изучили OpenAPI и Swagger, но мало у кого есть метод проектирования API.
Отсюда часто возникает вопрос: вот я прочитал много книг и статей про UML, юскейсы, API — но не понимаю, как всё это связать? Когда использовать одно, когда другое? В голове какая-то каша.
А нужен метод работы! Или, по руководству INCOSE, набор формальных преобразований. Здесь мы с ними сходимся: если вы в принципе готовы рассматривать идею "требований", как отдельно существующих вещей, то эти требования обязаны быть результатом формальных преобразований:
Формулировка требования — это итог формального преобразования одной или нескольких потребностей в согласованное обязательство. Это обязательство возлагают на сущность. Суть обязательства — при определенных ограничениях выполнять некоторую функцию или обладать некоторым качеством.
👍23🔥14👎1
Одним из самых главных инсайтов Flow для меня стало вот это разделение нотации и метода. Часто их не разделяют, и от этого много путаницы.
Вот смотрите:
UML — это нотация. Booch, OMT, OOSE, Iconix (и даже C4!) — методы применения этой нотации.
IDEF0 — это метод. Так и называется: "МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ", есть рекомендации по стандартизации Р 50.1.028-2001.
BPMN — нотация. Есть книга Брюса Сильвера 'BPMN Method and Style' (https://methodandstyle.com/books/bpmn-method-and-style/), вот в ней предложен метод создания BPMN-дигарамм.
DFD — нотация, а структурный анализ — набор методов.
DDD — набор идей и паттернов, Event Storming — метод.
Agile — декларация ценностей, SCRUM и SAFe — методы ведения деятельности по разработке ПО.
ГОСТ 34 — описание содержания документов, "Руководство по написанию требований INCOSE" — метод.
REST — набор принципов, OpenAPI — язык описаний API, 'Design and Build Great Web APIs' Майка Амундсена — метод их проектирования.
User Story — формат фиксации требований, а Impact mapping и User Story Mapping — методы работы с ними. А JTBD, например, не просто формат записи, но ещё и имеет некоторые элементы метода.
И так во всём. Если вы изучите нотацию или язык, но не изучите метод — вы не будете знать, что и как делать. И ценность, например, наших курсов в том, что мы не рассказываем о технологиях и нотациях, а даем метод их применения. Изучать нужно методы, и на собеседованиях спрашивать о методах работы!
Вот смотрите:
UML — это нотация. Booch, OMT, OOSE, Iconix (и даже C4!) — методы применения этой нотации.
IDEF0 — это метод. Так и называется: "МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ", есть рекомендации по стандартизации Р 50.1.028-2001.
BPMN — нотация. Есть книга Брюса Сильвера 'BPMN Method and Style' (https://methodandstyle.com/books/bpmn-method-and-style/), вот в ней предложен метод создания BPMN-дигарамм.
DFD — нотация, а структурный анализ — набор методов.
DDD — набор идей и паттернов, Event Storming — метод.
Agile — декларация ценностей, SCRUM и SAFe — методы ведения деятельности по разработке ПО.
ГОСТ 34 — описание содержания документов, "Руководство по написанию требований INCOSE" — метод.
REST — набор принципов, OpenAPI — язык описаний API, 'Design and Build Great Web APIs' Майка Амундсена — метод их проектирования.
User Story — формат фиксации требований, а Impact mapping и User Story Mapping — методы работы с ними. А JTBD, например, не просто формат записи, но ещё и имеет некоторые элементы метода.
И так во всём. Если вы изучите нотацию или язык, но не изучите метод — вы не будете знать, что и как делать. И ценность, например, наших курсов в том, что мы не рассказываем о технологиях и нотациях, а даем метод их применения. Изучать нужно методы, и на собеседованиях спрашивать о методах работы!
👍41🔥24👎2👌1
Kupriyanov_flow_UML.pdf
9.6 MB
Публикую презентацию с Flow про UML. Нужно тему сворачивать, а то уже, говорят, приклеилась слава, что "Куприянов всем говорит, что UML умер". Так вот — UML жив, и неплохо себя чувствует. Прямо по Жванецкому: "И что смешно — министр мясной и молочной промышленности есть и очень хорошо выглядит". Или как в "Кин-дза-дзе": "Побойся неба! ПЖ жив! И я счастлив!" (да, я бумер, и мемы у меня бумерские).
Так вот, что смешно: UML жив, и хорошо выглядит. Собственно, об этом в презентации. Основные тезисы:
80% опрошенных используют UML (хоть какие-то элементы из него). Впрочем, эта оговорка почти незначима — опрос показывает, что если уж вы начали использовать UML, то скорее вы используете в целом что-то похожее на стандартные диаграммы, а не отдельные элементы.
84% диаграмм — формальные. Наброски и "просто картинки" системные аналитики не рисуют.
Да, аналитиков в опросе было 59%, 19% — архитекторов, 13,5% — разработчики.
Разработчики меньше всего пользуются UML. Архитекторы — и так, и так. Аналитики — скорее будут рисовать UML, а не что-то другое. С разработчиками есть и ещё одна проблема — они даже говорить о UML не хотят, так что сложно было найти респондентов.
Что ещё: аналитики в основном работают в финтехе (больше всех), в екоме и гос.проектах. И в других отраслях россыпью, почти столько же, сколько в финтехе. Большинство работает в крупных или средних компаниях — почти 85%.
Там же чаще используют UML. Если вы фрилансер или работаете в маленькой компании, UML у вас скорее не используется.
Почти 42% работают в продуктовых компаниях (так что неверен тезис, что в продуктах нет системных аналитиков), 25% — во внутренней автоматизации.
К диаграммам: создают часто (в этот день, на днях, в течение этого месяца...), меняют тоже часто, почти все диаграммы сохраняют ("это часть документации!"). В основном рисуют, чтобы зафиксировать требования или презентовать решение/архитектуру.
Соответственно, на диаграмме будет архитектура или схема интеграции.
Поэтому неудивительно, что самая популярная диаграмма — Sequence Diagram. Её используют вдвое чаще, чем любую другую.
Удивительно, что на втором месте по частоте использования — Use Case Diagram, а за ней — State Machine и Activity. Остальные используют реже.
Применение agile никак на использование UML не влияет. От стажа работы использование UML зависит отрицательно: чем больше стаж, тем меньше применяют UML (корреляция небольшая, -0.26, но отрицательная).
Кроме UML используют BPMN (примерно треть опрошенных), C4 (10%), Archimate (21 человек из 275), а ещё ERD, IDEF0, DFD и EPC — но очень мало.
Вот такие основные выводы. Если есть идеи, что ещё можно было бы проверить на этих данных — пишите, посмотрим.
Так вот, что смешно: UML жив, и хорошо выглядит. Собственно, об этом в презентации. Основные тезисы:
80% опрошенных используют UML (хоть какие-то элементы из него). Впрочем, эта оговорка почти незначима — опрос показывает, что если уж вы начали использовать UML, то скорее вы используете в целом что-то похожее на стандартные диаграммы, а не отдельные элементы.
84% диаграмм — формальные. Наброски и "просто картинки" системные аналитики не рисуют.
Да, аналитиков в опросе было 59%, 19% — архитекторов, 13,5% — разработчики.
Разработчики меньше всего пользуются UML. Архитекторы — и так, и так. Аналитики — скорее будут рисовать UML, а не что-то другое. С разработчиками есть и ещё одна проблема — они даже говорить о UML не хотят, так что сложно было найти респондентов.
Что ещё: аналитики в основном работают в финтехе (больше всех), в екоме и гос.проектах. И в других отраслях россыпью, почти столько же, сколько в финтехе. Большинство работает в крупных или средних компаниях — почти 85%.
Там же чаще используют UML. Если вы фрилансер или работаете в маленькой компании, UML у вас скорее не используется.
Почти 42% работают в продуктовых компаниях (так что неверен тезис, что в продуктах нет системных аналитиков), 25% — во внутренней автоматизации.
К диаграммам: создают часто (в этот день, на днях, в течение этого месяца...), меняют тоже часто, почти все диаграммы сохраняют ("это часть документации!"). В основном рисуют, чтобы зафиксировать требования или презентовать решение/архитектуру.
Соответственно, на диаграмме будет архитектура или схема интеграции.
Поэтому неудивительно, что самая популярная диаграмма — Sequence Diagram. Её используют вдвое чаще, чем любую другую.
Удивительно, что на втором месте по частоте использования — Use Case Diagram, а за ней — State Machine и Activity. Остальные используют реже.
Применение agile никак на использование UML не влияет. От стажа работы использование UML зависит отрицательно: чем больше стаж, тем меньше применяют UML (корреляция небольшая, -0.26, но отрицательная).
Кроме UML используют BPMN (примерно треть опрошенных), C4 (10%), Archimate (21 человек из 275), а ещё ERD, IDEF0, DFD и EPC — но очень мало.
Вот такие основные выводы. Если есть идеи, что ещё можно было бы проверить на этих данных — пишите, посмотрим.
👍25🏆11❤5🔥2
Недавно слушал отличную лекцию про сценарии сериалов и про особенности кинопроизводства. Я давно интересуюсь способом организации производства в других отраслях, и кино, мне кажется, во многом похоже на ИТ (ну или ИТ на кино, всё-таки киноиндустрии уже больше ста лет, а ИТ всё ещё молодое 😉).
Вот смотрите:
Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.
Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии.
После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы.
После синопсиса иногда пишется тритмент — это расширенная версия всего сюжета, но ещё не сценарий. Он обычно 5-10 страниц, но может быть и больше. В тритменте вся история рассказывается в хронологическом порядке, но со стороны — тут ещё нет художественных приемов, последовательности, в которой историю увидит зритель, и нет диалогов.
Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)
И уже после этого пишется сценарий со всеми диалогами (причем часто сюжет придумывает один человек, а диалоги пишет другой, вот это разделение труда!). Диалоги пишут вообще в последний момент, и могут переписать прямо на площадке. Это как сценарии вариантов использования и конкретные объекты данных — самый детальный уровень проработки.
Когда сценарий готов и съемочная команда собрана — проходит классная вещь: режиссерская читка. На читку собираются представители всех цехов (операторы, декораторы и реквизиторы, гримеры, художники по костюмам, осветители, каскадеры, специалисты по спецэффектам и графике, и т.д. И продюсеры, конечно).
Всем раздают по своему экземпляру сценария, режиссер его читает и все делают пометки — что когда им делать, и задают вопросы. Сценаристы сидят в сторонке и отвечают только когда их спрашивают. Каждый цех проверяет и озвучивает детали, относящиеся к ним. Реквизитор спрашивает:
— А вот у вас герой выходит из здания, а сумка при нём?
— Какая сумка?
— Ну, две сцены назад у него была кожаная сумка, она сейчас с ним?
Или костюмер говорит: если вы хотите в этой сцене героя облить супом, то нужно будет минимум 3 экземпляра его костюма, а лучше 5.
Дрессировщик говорит: тут у вас обезьяна со злостью стучит по решетке. Это можно, но потом ей нужно будет недели две успокаиваться, имейте в виду.
Продюсер говорит: тут у вас гонки, но это очень дорого, давайте что-то другое.
И сценарист начинает переделывать или уточнять сценарий после всех замечаний.
Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!
Вот смотрите:
Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.
Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии.
После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы.
После синопсиса иногда пишется тритмент — это расширенная версия всего сюжета, но ещё не сценарий. Он обычно 5-10 страниц, но может быть и больше. В тритменте вся история рассказывается в хронологическом порядке, но со стороны — тут ещё нет художественных приемов, последовательности, в которой историю увидит зритель, и нет диалогов.
Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)
И уже после этого пишется сценарий со всеми диалогами (причем часто сюжет придумывает один человек, а диалоги пишет другой, вот это разделение труда!). Диалоги пишут вообще в последний момент, и могут переписать прямо на площадке. Это как сценарии вариантов использования и конкретные объекты данных — самый детальный уровень проработки.
Когда сценарий готов и съемочная команда собрана — проходит классная вещь: режиссерская читка. На читку собираются представители всех цехов (операторы, декораторы и реквизиторы, гримеры, художники по костюмам, осветители, каскадеры, специалисты по спецэффектам и графике, и т.д. И продюсеры, конечно).
Всем раздают по своему экземпляру сценария, режиссер его читает и все делают пометки — что когда им делать, и задают вопросы. Сценаристы сидят в сторонке и отвечают только когда их спрашивают. Каждый цех проверяет и озвучивает детали, относящиеся к ним. Реквизитор спрашивает:
— А вот у вас герой выходит из здания, а сумка при нём?
— Какая сумка?
— Ну, две сцены назад у него была кожаная сумка, она сейчас с ним?
Или костюмер говорит: если вы хотите в этой сцене героя облить супом, то нужно будет минимум 3 экземпляра его костюма, а лучше 5.
Дрессировщик говорит: тут у вас обезьяна со злостью стучит по решетке. Это можно, но потом ей нужно будет недели две успокаиваться, имейте в виду.
Продюсер говорит: тут у вас гонки, но это очень дорого, давайте что-то другое.
И сценарист начинает переделывать или уточнять сценарий после всех замечаний.
Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!
🔥59❤🔥9❤6👍2🤔1
Про концепции продуктов. Для кино есть логлайн, для [ИТ-]продуктов есть формула, в которой отражены примерно похожие вещи.
Состав концепции:
* описание аудитории — для кого мы делаем продукт или решение? Это могут быть люди в определенной ситуации, или сотрудники с какой-то ролью, елси продукт внутренний.
* задача, которую решают эти люди — чего они хотят или что им нужно делать по работе.
* препятствие — что мешает им выполнять эту задачу
* что мы для них делаем (какую систему создаем)
* как они будут решать свою проблему, когда система будет готова
* за счет чего проблема будет решена? (какое ключевое свойство нашего решения)
Можно ещё добавить анализ альтернатив: в чем отличие от других способов решения и в чем выигрыш.
В виде формулы это выглядит так:
Примеры:
"Для системных аналитиков, которые знают много отдельных техник, но не могут их сложить в единый процесс, потому что в книгах описаны отдельные свойства, нотации и инструменты, но не описана логика их применения, мы делаем курс по разработке требований, который помогает выстроить четкую последовательность действий за счет того, что дает последовательный алгоритм выявления требований и проектирования решения".
Ладно, это шутка. Или нет. Вот очередной курс будет в конце октября.
Давайте посмотрим пример ИТ-систем:
"Для клиентов с открытыми брокерскими счетами, которые осуществляют мало операций, потому что не понимают, что им покупать, мы создаем сервис готовых стратегий, к которому можно будет подключиться, и в нём уже будут подобранные акции и облигации, стоп-ордеры и тейк-профиты, так что клиентам после присоединения к стратегии и делать ничего самим не придётся".
"Для сотрудников подразделения KYC, которым нужно проверять действительность паспортов согласно требованиям 115-ФЗ, но они не могут это сейчас делать, потому что сервис МВД по проверке паспортов перестал работать, мы делаем интеграционное решение, которое позволит отправлять запрос через СМЭВ-4 в автоматическом режиме по ключевым событиям, что позволит сотрудникам не проверять паспорта вручную, а только мониторить этот процесс и получать оповещения о недействительности паспорта."
"Для студентов, которые хотят проходить курсы от ведущих российских вузов, а не в своем, где препод толкает чушь, но не могут, потому что живут в других городах или не смогли в эти вузы поступить, мы делаем онлайн-платформу с открытыми курсами, где можно будет пройти курс и даже зачесть его в своем вузе."
Зачем составлять концепцию? Как минимум, чтобы все согласились и были на одной волне. Концепция задает основных потребителей и ключевую функцию. Из неё следуют все остальные решения и приоритеты. Вот например, в последнем варианте реальная концепция была совсем другой:
"Для администраций региональных вузов, которые хотят обеспечить высокое качество непрофильных курсов и выполнить показатели по числу сетевых программ, мы делаем платформу с онлайн-курсами, на которой вузы смогут заключать сетевые договоры, зачислять своих студентов на курсы и отслеживать их успеваемость"
Чувствуете? Вообще всё другое: и целевая аудитория, и цель, и основные функции (вместо фокуса на удобстве обучения — фокус на удобстве заключения и администрирования договоров).
Такую концепцию можно согласовывать с заказчиками, и дальше уже развивать и детализировать.
Следующим шагом это всё превращается в развернутую таблицу, страницы на две, где кроме перечисленных выше параметров будет чуть более развернутое описание: как сейчас и как будет, измеримые показатели положительных изменений, сроки актуальности проекта и описание окружения (а то и первичный набросок архитектуры).
Состав концепции:
* описание аудитории — для кого мы делаем продукт или решение? Это могут быть люди в определенной ситуации, или сотрудники с какой-то ролью, елси продукт внутренний.
* задача, которую решают эти люди — чего они хотят или что им нужно делать по работе.
* препятствие — что мешает им выполнять эту задачу
* что мы для них делаем (какую систему создаем)
* как они будут решать свою проблему, когда система будет готова
* за счет чего проблема будет решена? (какое ключевое свойство нашего решения)
Можно ещё добавить анализ альтернатив: в чем отличие от других способов решения и в чем выигрыш.
В виде формулы это выглядит так:
Для <описание аудитории>, которые хотят <описание задачи>, но не могут, потому что <описание препятствия>, мы делаем <тип решения>, которое поможет им <описание решения проблемы>, за счет того, что <ключевое свойство решения>.
Примеры:
"Для системных аналитиков, которые знают много отдельных техник, но не могут их сложить в единый процесс, потому что в книгах описаны отдельные свойства, нотации и инструменты, но не описана логика их применения, мы делаем курс по разработке требований, который помогает выстроить четкую последовательность действий за счет того, что дает последовательный алгоритм выявления требований и проектирования решения".
Ладно, это шутка. Или нет. Вот очередной курс будет в конце октября.
Давайте посмотрим пример ИТ-систем:
"Для клиентов с открытыми брокерскими счетами, которые осуществляют мало операций, потому что не понимают, что им покупать, мы создаем сервис готовых стратегий, к которому можно будет подключиться, и в нём уже будут подобранные акции и облигации, стоп-ордеры и тейк-профиты, так что клиентам после присоединения к стратегии и делать ничего самим не придётся".
"Для сотрудников подразделения KYC, которым нужно проверять действительность паспортов согласно требованиям 115-ФЗ, но они не могут это сейчас делать, потому что сервис МВД по проверке паспортов перестал работать, мы делаем интеграционное решение, которое позволит отправлять запрос через СМЭВ-4 в автоматическом режиме по ключевым событиям, что позволит сотрудникам не проверять паспорта вручную, а только мониторить этот процесс и получать оповещения о недействительности паспорта."
"Для студентов, которые хотят проходить курсы от ведущих российских вузов, а не в своем, где препод толкает чушь, но не могут, потому что живут в других городах или не смогли в эти вузы поступить, мы делаем онлайн-платформу с открытыми курсами, где можно будет пройти курс и даже зачесть его в своем вузе."
Зачем составлять концепцию? Как минимум, чтобы все согласились и были на одной волне. Концепция задает основных потребителей и ключевую функцию. Из неё следуют все остальные решения и приоритеты. Вот например, в последнем варианте реальная концепция была совсем другой:
"Для администраций региональных вузов, которые хотят обеспечить высокое качество непрофильных курсов и выполнить показатели по числу сетевых программ, мы делаем платформу с онлайн-курсами, на которой вузы смогут заключать сетевые договоры, зачислять своих студентов на курсы и отслеживать их успеваемость"
Чувствуете? Вообще всё другое: и целевая аудитория, и цель, и основные функции (вместо фокуса на удобстве обучения — фокус на удобстве заключения и администрирования договоров).
Такую концепцию можно согласовывать с заказчиками, и дальше уже развивать и детализировать.
Следующим шагом это всё превращается в развернутую таблицу, страницы на две, где кроме перечисленных выше параметров будет чуть более развернутое описание: как сейчас и как будет, измеримые показатели положительных изменений, сроки актуальности проекта и описание окружения (а то и первичный набросок архитектуры).
👍19❤7🔥6
Написал супер-краткий конспект книги Вигерса. А то тут ходит конспект на 70 страниц, и люди просят краткое изложение краткого конспекта. Итак, специально для тех, у кого нет времени читать ни 700, ни 70 страниц, циничный конспект:
Часть I. Требования к ПО
* Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные).
Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой:
Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно.
Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость:
Схема на стр.51 показывает главную идею: не ждите, что все действия по разработке требований удастся выполнить последовательно и за один проход. Выявление, анализ, спецификация и валидация будут происходить одновременно.
Часть II. Разработка требований.
* Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет.
* Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют.
* Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер.
* Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
* Поиск упущенных требований — стр. 136.
* Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193.
* Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.
Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234.
* Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.
Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно.
* Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё.
* Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
* Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить.
* Прототипирование — скорее всего, его у вас нет. Пропускаете.
* Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях".
* Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
* Повторное использование требований, гл. 18. Не бывает.
ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой.
Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.
Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет.
Итого, нужно просмотреть несколько страниц из первой части, потом шаблон SRS и раздел про тексты.
Вот и всё, не благодарите.
(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)
Часть I. Требования к ПО
* Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные).
Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой:
Инженерия требований состоит из разработки требований и управления требованиями. Разработка требований состоит из этапов выявления, анализа, спецификации и валидации.
Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно.
Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость:
В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, but you’re managing the communications closely.
Схема на стр.51 показывает главную идею: не ждите, что все действия по разработке требований удастся выполнить последовательно и за один проход. Выявление, анализ, спецификация и валидация будут происходить одновременно.
Часть II. Разработка требований.
* Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет.
* Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют.
* Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер.
* Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
* Поиск упущенных требований — стр. 136.
* Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193.
* Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.
Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234.
* Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.
Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно.
* Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё.
* Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
* Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить.
* Прототипирование — скорее всего, его у вас нет. Пропускаете.
* Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях".
* Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
* Повторное использование требований, гл. 18. Не бывает.
ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой.
Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.
Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет.
Итого, нужно просмотреть несколько страниц из первой части, потом шаблон SRS и раздел про тексты.
Вот и всё, не благодарите.
(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)
😁71🔥27👍22❤6👎3
Я знаю, что дошучивать не хорошо, но вчера в пост всё не уместилось — ещё в книге Вигерса есть части, которые будут полезны для лидов или тех, кто хочет им стать.
Например, страницы с 20 по 25 помогут вам аргументировать вашу полезность, если у начальства есть сомнения. Зачем вообще нужны эти аналитики?! Вот там перечислены пугалки и вероятные выгоды (см. главу про риски). В основном все пугалки сводятся к разрастанию скоупа и дороговизне исправления ошибок в коде, а не в спецификации. Проверьте, что в вашем случае это действительно так.
Стр. 36-40 — обязанности заказчика. Очень интересный раздел. Можете эти пункты вставлять в договоры. Всё равно никто им не следует. Можно зачитывать вслух, чтобы вместе посмеяться с командой за пивом. Или поплакать. Я их даже приведу тут, порыдаем вместе:
Обязанность №1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса. Ну допустим.
Обязанность №2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований. Уже рыдаю.
Обязанность №3. Точно и конкретно описать требования к системе. Началась бульварная фантастика.
Обязанность №4. По запросу принимать своевременные решения относительно требований. Фантастика продолжается.
Обязанность №5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований. Я уважаю вашу оценку, но нам нужно это вчера и за 1/10 стоимости.
Обязанность №6. Определять реалистичные приоритеты требований совместно с разработчиками. Говорю же — нужно вчера.
Обязанность №7. Проверять требования и оценивать прототипы. Покажите финальный дизайн.
Обязанность №8. Определить критерии приемки. Вот увижу, тогда скажу — то или не то.
Обязанность №9. Своевременно сообщать об изменениях требований.😭
Обязанность №10. Уважительно относиться к процессам создания требований. См. п. 5.
До этого на стр. 33-36 есть "Билль о правах заказчика" — там самое интересное Право №5. Заказчик имеет право изменить свои требования. Вот в это охотно верю.
Дальше опять про культуру уважения к требованиям и про утверждение требований (стр. 40-47). Вот тут есть фраза, которую нужно отлить в граните:
"Оба описанных" — это позиция заказчика «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!» и аргумент менеджера «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше».
Слышите! Сам Вигерс нам сказал, что нельзя знать всех требований заранее!
Про это же в главе 17, которая в русском переводе "Утверждение", а на английском — Validation (читайте оригинал!). Как я уже писал, там про рецензирование и проверки. Лидам актуально. Там, к слову, описана та самая "читка" — Вигер называет её "inspection" (а переводчик — "экспертизой"). И ещё есть чеклист на стр. 400, приведу его отдельно.
Ну и для лидов уже наоборот — обязательна к прочтению Часть V, где про улучшение процессов и про риски.
Впрочем, улучшение процессов у Вигерса дано обзорно, какой-то специфики именно в анализе тут нет, обычный проект изменений.
Тут уже и сам Вигерс шутит:
* не откусывайте кусок, который не сможете прожевать
* получайте максимум удовольствия от малых побед (больших побед у вас будет немного)
* давите мягко, но постоянно
* концентрируйтесь (команда разработчиков может выполнять только одно улучшение за раз).
* ищите союзников (растите их; благодарите их; награждайте их)
А главный тезис, про который нужно всегда помнить: при совершенствовании процессов производительность сначала ухудшается, и только потом улучшается выше предыдущего значения (кто сказал, что она улучшится?)
Ну и про риски — они у Вигерса перечислены, но в принципе все укладываются в две категории:
* сделали не то, что нужно
* не сделали то, что нужно
Вот такое дополнение. Поздравляю, теперь вы готовы к роли лида аналитиков!
Например, страницы с 20 по 25 помогут вам аргументировать вашу полезность, если у начальства есть сомнения. Зачем вообще нужны эти аналитики?! Вот там перечислены пугалки и вероятные выгоды (см. главу про риски). В основном все пугалки сводятся к разрастанию скоупа и дороговизне исправления ошибок в коде, а не в спецификации. Проверьте, что в вашем случае это действительно так.
Стр. 36-40 — обязанности заказчика. Очень интересный раздел. Можете эти пункты вставлять в договоры. Всё равно никто им не следует. Можно зачитывать вслух, чтобы вместе посмеяться с командой за пивом. Или поплакать. Я их даже приведу тут, порыдаем вместе:
Обязанность №1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса. Ну допустим.
Обязанность №2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований. Уже рыдаю.
Обязанность №3. Точно и конкретно описать требования к системе. Началась бульварная фантастика.
Обязанность №4. По запросу принимать своевременные решения относительно требований. Фантастика продолжается.
Обязанность №5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований. Я уважаю вашу оценку, но нам нужно это вчера и за 1/10 стоимости.
Обязанность №6. Определять реалистичные приоритеты требований совместно с разработчиками. Говорю же — нужно вчера.
Обязанность №7. Проверять требования и оценивать прототипы. Покажите финальный дизайн.
Обязанность №8. Определить критерии приемки. Вот увижу, тогда скажу — то или не то.
Обязанность №9. Своевременно сообщать об изменениях требований.
Обязанность №10. Уважительно относиться к процессам создания требований. См. п. 5.
До этого на стр. 33-36 есть "Билль о правах заказчика" — там самое интересное Право №5. Заказчик имеет право изменить свои требования. Вот в это охотно верю.
Дальше опять про культуру уважения к требованиям и про утверждение требований (стр. 40-47). Вот тут есть фраза, которую нужно отлить в граните:
Оба описанных подхода игнорируют реальность, которая такова, что на ранних этапах работы над проектом нельзя знать абсолютно всех требований и со временем они неизбежно меняются.
"Оба описанных" — это позиция заказчика «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!» и аргумент менеджера «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше».
Слышите! Сам Вигерс нам сказал, что нельзя знать всех требований заранее!
Про это же в главе 17, которая в русском переводе "Утверждение", а на английском — Validation (читайте оригинал!). Как я уже писал, там про рецензирование и проверки. Лидам актуально. Там, к слову, описана та самая "читка" — Вигер называет её "inspection" (а переводчик — "экспертизой"). И ещё есть чеклист на стр. 400, приведу его отдельно.
Ну и для лидов уже наоборот — обязательна к прочтению Часть V, где про улучшение процессов и про риски.
Впрочем, улучшение процессов у Вигерса дано обзорно, какой-то специфики именно в анализе тут нет, обычный проект изменений.
Тут уже и сам Вигерс шутит:
* не откусывайте кусок, который не сможете прожевать
* получайте максимум удовольствия от малых побед (больших побед у вас будет немного)
* давите мягко, но постоянно
* концентрируйтесь (команда разработчиков может выполнять только одно улучшение за раз).
* ищите союзников (растите их; благодарите их; награждайте их)
А главный тезис, про который нужно всегда помнить: при совершенствовании процессов производительность сначала ухудшается, и только потом улучшается выше предыдущего значения (кто сказал, что она улучшится?)
Ну и про риски — они у Вигерса перечислены, но в принципе все укладываются в две категории:
* сделали не то, что нужно
* не сделали то, что нужно
Вот такое дополнение. Поздравляю, теперь вы готовы к роли лида аналитиков!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤30🔥22😁11👍7