В статье фотография не из того КВИРТУ. В Киеве в 50-е было два училища с похожими названиями: КВИРТУ ВВС и КВИРТУ ПВО.
Судя по описанию, он успел поучиться в КВИРТУ ВВС, позже переименованном в КВВАИУ (Киевское высшее военное авиационное училище). Это оно было расположено на Воздухофлотском проспекте.
А КВИРТУ ПВО было создано только в 1953 году, так что в 52-м он никак не мог туда поступить.
Главное, что я вынес из книг Купера, который разработал этот метод: персоны нужны для того, чтобы запустить «встроенный механизм» эмпатии при анализе потребностей пользователей. Разработчики должны относиться к персонажу, как к реальному человеку. Для этого и придумывается имя, выбирается лицо и добавляются мелкие детали привычек и характера, которые напрямую никак не связаны с создаваемым продуктом. А исследование перед созданием персон необходимо для выявления поведенческих переменных, которые позволят создать портреты для кластеров, наиболее близких к реальным (и желаемым) потребителям.
У вас эмпатия почему-то упоминается только как случайный эффект, который может возникнуть у саппорта. Но это не так, ведь только ради неё всё и затевалось! Иначе вполне хватит обычных маркетинговых стереотипов (одинокая домохозяйка со средним доходом).
IMHO, кстати, как раз саппорту персоны не нужны, потому что он и так работает с реальными людьми. В отличие от разработчиков продукта, которые обычно изолированы от своего потребителя и нуждаются в его релевантной модели.
Так зачем нужны персоны?
«Гики, которые смотрят Теорию большого взрыва» — это тот самый стереотип, который почему-то категорически не рекомендуется использовать. Хотя он вполне соответствует критерию «отражать какую-то часть реальных пользователей». А если провести качественное исследование потребителей, то и стереотип будет качественным, отражающим не «какую-то», а существенную часть.
Зачем тогда все эти сложности — фотография, имя, особенности характера?
Можно ещё провести такой опрос среди финансовых аналитиков, биржевых аналитиков и химиков-аналитиков. Тыжаналитик, вот и проанализируй мне метрики продукта!
Но почему не использовать «плавательные дорожки» для участников процесса? Как это принято в BPMN и допускается в UML. Сейчас диаграмма процесса практически нечитаема (при том, что он довольно простой) из-за большого числа стрелок и забора из разделителей, не имеющих особого смысла. Размещение акторов на отдельных дорожках сразу уберёт половину стрелок, замусоривающих диаграмму.
Главная проблема диаграммы Гантта не в том, что она становится сложной и трудносопровождаемой, а в том, что она создаёт видимость чёткого плана там, где его нет, а часто и не может быть.
ГОСТ 34 устарел именно из-за того, что это стандарт для разработки автоматизированных систем. А большинство разрабатываемых сейчас систем выходит за рамки определения АС. К сожалению, на это определение внимательно никто не смотрит, и сплошь и рядом считают, что любой программный продукт можно подвести под это определение.
В первую очередь, он устарел как раз из-за того, что в АС люди считаются «персоналом» — винтиками системы. Это отношение к людям как к персоналу выводит на первый план потребности организации и реализацию необходимых только ей функций. Это было так, когда вычислительные машины были большими и дорогими, это перестало быть так с появленим персональных компьютеров, и стало совсем не так с массовым распространением интернета.
При попытке применить ГОСТовский подход к системам, предоставляющим какой-то сервис для людей, получается как в анекдоте про детскую коляску и автомат Калашникова. Это было очень хорошо видно по первой версии портала госуслуг, например. И по-прежнему видно по сайтам, разрабатываемым по заказам госорганизаций, где ГОСТ очень любят.
Устарела и сама концепция видов обеспечения. Люди упорно пишут в раздел требований к лингвистическому обеспечению что-то вроде "интерфейс пользователя должен быть на русском языке". И правильно делают, потому что проблема лингвистического обеспечения давно решена и опустилась с уровня бизнес-требований в самый низ, на уровень реализации.
Опасность ГОСТа в том, что он кажется со стороны полноценной и законченной методикой разработки требований. Но, во-первых, он ей не является. Стандарт описывает результаты работ по выявлению и описанию требований, но не говорит практически ничего об их содержании. А во-вторых, он токсичен. Начав работать по ГОСТу, вы всё больше погружаетесь в болото его концепций. Эти концепции очень трудно изжить. Если вы после этого перейдёте в проект разработки продукта, который не подходит под определение АС, то ГОСТовский образ мышления будет отравлять ваш продукт. Вы будете думать в первую очередь о функциях, и в последнюю о людях (лично я это постоянно вокруг себя наблюдаю).
Если вам всё же не повезло в этой жизни, и вы вынуждены работать по ГОСТу, то, кроме искреннего сочувствия, могу вам посоветовать изучить его предшественника: серию стандартов ГОСТ 24. Тогда речь шла даже не об АС, а об АСУ — автоматизированных системах управления. Сама концепция АСУ вам вряд ли пригодится, но вы, по крайней мере, лучше поймёте значение многих терминов, которые используются в ГОСТ 34. Разработчики ГОСТ 34 использовали эти термины в предположении, что их и так уже все знают, поэтому ГОСТ 34 очень (даже слишком) лаконичен.
Да, не всем. Но я им пользуюсь именно как платёжным агрегатором: с моего сайта для оплаты пользователь переходит на карточку товара на Маркете, там оплачивает и получает чек, а мой сайт тут же регистрирует оплату через api робомаркета.
Не указано самое важное отличие Робомаркета, связанное с 54-ФЗ: он является ещё и платёжным агентом. То есть сам выдаёт чеки покупателям: дополнительная интеграция с онлайн-кассой не нужна!
При подключении яндекс.кассы и робокассы вопрос с 54-ФЗ остаётся открытым. Да, они предлагают интеграцию с сервисом аренды онлайн-касс. А это, не считая затрат на саму интеграцию, ещё от ~3600 руб. в месяц.
imho самые лучшие термины — те, которые больше ни с чем не ассоциируются, и поэтому однозначно идентифицируют то, что означают. Термины «vision» и «usecase» лучше, чем «концепция» и «вариант использования».
В своё время usecase неграмотно перевели как «прецедент» (взяли из юридического словаря). Так этот вариант перевода, на мой взгляд, оказался самым удачным именно потому, что в айтишной лексике он больше ни к чему не привязан.
Не зря в Agile (тоже отличное иностранное слово) используют термины вроде «бэклог», «спринт» и т. п. — ни у кого не возникает ложных ассоциаций с другими сущностями.
А зачем разбирать терминологию из первого издания Вигерса, если вышло уже третье, в том числе в русском переводе? В котором уже нет ни «границ проекта», ни «документа о вариантах использования».
Война с призраками.
Не совсем бессмысленный. Бизнес-требования, перечень функций и основные ограничения обычно вполне можно зафиксировать до начала работы, если речь идёт о разработке сайта.
… в приведенном выше примере таблицы ролей, нет описания целей заинтересованных лиц и т.п. Эти подробности важны для аналитика на этапе формирования требований, но практически бесполезны для разработчиков.
В данном случае — для кодеров, а не для разработчиков. Потому что разрабатывать тут уже нечего.
Вообще, в этой части подробно описано, как аналитик ворует работу у программистов и архитекторов, принимая за них все решения. А потом аналитики собирают митапы, чтобы обсудить вопрос "Почему программисты не читают требования".
Идея такого искусственного интеллекта постоянно приходит в голову разным пытливым умам. Одна из известных реализаций — Мыши Дебиляриуса.
А мой одногруппник ещё в 1988 году написал интерактивный гороскоп на языке REXX (под VM/370), который вежливо задавал вопросы, а потом выдавал на основании полученных ответов такую характеристику, что этого моего одногруппника неоднократно пытались побить. Но я уверен, что подобные вещи делали и намного раньше.
Очень типичное поведение для производителей таких продуктов: вместо того, чтобы вникать в потребности заказчиков, попытаться заставить этих заказчиков мыслить внутренними категориями системы. Этим грешат разработчики практически всех систем автоматизации бизнес-процессов (включая ERP, банковские и прочие).
«Что вы там мямлите про новую инструкцию ЦБ? Вы мне дайте перечень бизнес-объектов, матрицу ролевого доступа и опишите триггеры для проверки данных!»
А проблема решается только так: между заказчиком и программистом должен стоять бизнес-аналитик, способный переводить с одного языка а другой. А не «консультант и методолог».
Судя по описанию, он успел поучиться в КВИРТУ ВВС, позже переименованном в КВВАИУ (Киевское высшее военное авиационное училище). Это оно было расположено на Воздухофлотском проспекте.
А КВИРТУ ПВО было создано только в 1953 году, так что в 52-м он никак не мог туда поступить.
У вас эмпатия почему-то упоминается только как случайный эффект, который может возникнуть у саппорта. Но это не так, ведь только ради неё всё и затевалось! Иначе вполне хватит обычных маркетинговых стереотипов (одинокая домохозяйка со средним доходом).
IMHO, кстати, как раз саппорту персоны не нужны, потому что он и так работает с реальными людьми. В отличие от разработчиков продукта, которые обычно изолированы от своего потребителя и нуждаются в его релевантной модели.
«Гики, которые смотрят Теорию большого взрыва» — это тот самый стереотип, который почему-то категорически не рекомендуется использовать. Хотя он вполне соответствует критерию «отражать какую-то часть реальных пользователей». А если провести качественное исследование потребителей, то и стереотип будет качественным, отражающим не «какую-то», а существенную часть.
Зачем тогда все эти сложности — фотография, имя, особенности характера?
Но почему не использовать «плавательные дорожки» для участников процесса? Как это принято в BPMN и допускается в UML. Сейчас диаграмма процесса практически нечитаема (при том, что он довольно простой) из-за большого числа стрелок и забора из разделителей, не имеющих особого смысла. Размещение акторов на отдельных дорожках сразу уберёт половину стрелок, замусоривающих диаграмму.
www.greesha.ru/livejournal/символ-несбывшихся-надежд
В первую очередь, он устарел как раз из-за того, что в АС люди считаются «персоналом» — винтиками системы. Это отношение к людям как к персоналу выводит на первый план потребности организации и реализацию необходимых только ей функций. Это было так, когда вычислительные машины были большими и дорогими, это перестало быть так с появленим персональных компьютеров, и стало совсем не так с массовым распространением интернета.
При попытке применить ГОСТовский подход к системам, предоставляющим какой-то сервис для людей, получается как в анекдоте про детскую коляску и автомат Калашникова. Это было очень хорошо видно по первой версии портала госуслуг, например. И по-прежнему видно по сайтам, разрабатываемым по заказам госорганизаций, где ГОСТ очень любят.
Устарела и сама концепция видов обеспечения. Люди упорно пишут в раздел требований к лингвистическому обеспечению что-то вроде "интерфейс пользователя должен быть на русском языке". И правильно делают, потому что проблема лингвистического обеспечения давно решена и опустилась с уровня бизнес-требований в самый низ, на уровень реализации.
Опасность ГОСТа в том, что он кажется со стороны полноценной и законченной методикой разработки требований. Но, во-первых, он ей не является. Стандарт описывает результаты работ по выявлению и описанию требований, но не говорит практически ничего об их содержании. А во-вторых, он токсичен. Начав работать по ГОСТу, вы всё больше погружаетесь в болото его концепций. Эти концепции очень трудно изжить. Если вы после этого перейдёте в проект разработки продукта, который не подходит под определение АС, то ГОСТовский образ мышления будет отравлять ваш продукт. Вы будете думать в первую очередь о функциях, и в последнюю о людях (лично я это постоянно вокруг себя наблюдаю).
Если вам всё же не повезло в этой жизни, и вы вынуждены работать по ГОСТу, то, кроме искреннего сочувствия, могу вам посоветовать изучить его предшественника: серию стандартов ГОСТ 24. Тогда речь шла даже не об АС, а об АСУ — автоматизированных системах управления. Сама концепция АСУ вам вряд ли пригодится, но вы, по крайней мере, лучше поймёте значение многих терминов, которые используются в ГОСТ 34. Разработчики ГОСТ 34 использовали эти термины в предположении, что их и так уже все знают, поэтому ГОСТ 34 очень (даже слишком) лаконичен.
При подключении яндекс.кассы и робокассы вопрос с 54-ФЗ остаётся открытым. Да, они предлагают интеграцию с сервисом аренды онлайн-касс. А это, не считая затрат на саму интеграцию, ещё от ~3600 руб. в месяц.
В своё время usecase неграмотно перевели как «прецедент» (взяли из юридического словаря). Так этот вариант перевода, на мой взгляд, оказался самым удачным именно потому, что в айтишной лексике он больше ни к чему не привязан.
Не зря в Agile (тоже отличное иностранное слово) используют термины вроде «бэклог», «спринт» и т. п. — ни у кого не возникает ложных ассоциаций с другими сущностями.
Война с призраками.
В данном случае — для кодеров, а не для разработчиков. Потому что разрабатывать тут уже нечего.
Вообще, в этой части подробно описано, как аналитик ворует работу у программистов и архитекторов, принимая за них все решения. А потом аналитики собирают митапы, чтобы обсудить вопрос "Почему программисты не читают требования".
А мой одногруппник ещё в 1988 году написал интерактивный гороскоп на языке REXX (под VM/370), который вежливо задавал вопросы, а потом выдавал на основании полученных ответов такую характеристику, что этого моего одногруппника неоднократно пытались побить. Но я уверен, что подобные вещи делали и намного раньше.
«Что вы там мямлите про новую инструкцию ЦБ? Вы мне дайте перечень бизнес-объектов, матрицу ролевого доступа и опишите триггеры для проверки данных!»
А проблема решается только так: между заказчиком и программистом должен стоять бизнес-аналитик, способный переводить с одного языка а другой. А не «консультант и методолог».