Жаргон как средство повышения эффективности работы над проектом
•Download as PPTX, PDF•
0 likes•799 views
Доклад Сергея Оводова на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (11)
Similar to Жаргон как средство повышения эффективности работы над проектом
Similar to Жаргон как средство повышения эффективности работы над проектом (20)
More from SQALab
More from SQALab (20)
Жаргон как средство повышения эффективности работы над проектом
- 1. Жаргон как средство повышения эффективности работы над проектом
- 2. Коротко о компании Компания М13 занимается разработкой ИС в области мониторинга СМИ и соцсетей. Особенности процесса: ● b2b продукт ● продуктовая разработка с элементами заказной ● команды по 4-5 человек (аналитик, 2-3 разработчика, тестировщик) ● итеративный процесс ● применяется объектно-ориентированный анализ
- 3. Жаргон - инструмент общения Жаргон - набор понятий, принятых в рамках проекта (примерно то же, что глоссарий). Жаргон позволяет упростить общение внутри проекта, а также помогает избегать ошибок. Аналитик Тестировщик Менеджер Разработчик
- 4. Часть 1. Как помогает жаргон? Примеры
- 5. Пример 1. Корзина 1. Пользователь выбирает товар. 2. Система добавляет товар в список выбранных для покупки товаров пользователя. 3. Пользователь переходит к оформлению заказа. 4. Система отображает список выбранных для покупки товаров пользователя. 5. Пользователь подтверждает заказ. 6. Система создает заказ, копирует список выбранных для покупки товаров в заказ и очищает список выбранных для покупки товаров.
- 6. Вводим аббревиатуру 1. Пользователь выбирает товар. 2. Система добавляет товар в СВДПТ пользователя. 3. Пользователь переходит к оформлению заказа. 4. Cистема отображает СВДПТ пользователя. 5. Пользователь подтверждает заказ. 6. Система создает заказ, копирует СВДПТ в заказ и очищает СВДПТ.
- 7. Сравните, насколько проще 1. Пользователь выбирает товар. 2. Система добавляет товар в корзину. 3. Пользователь переходит к оформлению заказа. 4. Система отображает содержимое корзины. 5. Пользователь подтверждает заказ. 6. Система создает заказ, копирует товары из корзины в заказ и очищает корзину.
- 8. Пример 2. Интернет-банк 1. Специальный клиентский именованный счет может иметь название. Длина названия - от 3 до 30 символов. 2. Специальный клиентский именованный счет может быть открыт только через интернет-банк. Счет этого типа не должны быть доступны из банкоматов и приложений для операционистов. 3. На остаток по специальному клиентскому именованному счету должны начисляться проценты по минимальной ставке депозита.
- 9. Вводим аббревиатуру 1. СКИС может иметь название. Длина - от 3 до 30 символов. 2. СКИС может быть открыт только через интернет-банк. СКИС не могут быть доступны из банкоматов и приложений для операционистов. 3. На остаток по СКИС должны начисляться проценты по минимальной ставке депозита. Объем текста сократился на 20%
- 10. Аббревиатуры не идеальны Слово “СКИС” ● не ассоциируется с банковским счетом ● не подходит по стилю В реальности был выбран термин цель.
- 11. Пример 3. Карусель Карусель - система трекинга задач (аналог Jira, Bugzilla, etc.) задачи имеют жизненный цикл, описанный набором статусов
- 12. Глоссарий На экране "планирование" должны отображаться все задачи, включенные в очередную итерацию
- 13. Фактическая модель Возникло противоречие в терминах, потому что ранее термин “задача” уже был использован
- 14. Уточненная модель Талон - общее название запросов на изменение кода Фича - Талон на реализацию новых требований Баг - талон на исправление дефекта.
- 15. Пример 4. Уведомления отправитель и все получатели должны относиться к одной компании
- 16. Добавляем новую связь отправитель и все получатели должны относиться к одной компании
- 17. Сотрудник - пользователь, который работает в заданной компании. Партнер - пользователь, который связан с компанией, но не является её сотрудником Адресат - сотрудник или партнер компании Уточненная модель
- 18. Выводы по части 1 1. Жаргон упрощает речь и способствует более эффективному взаимодействию проектной команды. 2. Жаргон позволяет повысить качество требований, снизить количество ошибок. 3. Формирование жаргона требует усилий.
- 19. Часть 2. Практика формирования жаргона
- 20. Симптомы словарного дефицита 1. Появление устойчивых словосочетаний 2. Затруднение в объяснении или записи требований 3. Частое использование слова “который” 4. Конфликт терминов
- 21. Способы генерации терминов 1. Поиск 2. Аббревиатура 3. Транслитерация 4. Метафора
- 22. Однозначность - самое главное Неоднозначно ~ неточно ~ неверно “Сотрудник” и “партнер” лучше, чем “связан” или “относится” “Фича” лучше, чем “Задача” Критерии качества терминов Важно: спецтермин должен говорить о том, что он спецтермин
- 23. Произносимость СКИС лучше, чем СВДПТ Интуитивность “Фича” лучше, чем ЗРНТ (запрос на реализацию новых требований) Согласованность Товары находятся в “Корзине” Стиль “Цель” лучше, чем СКИС
- 24. Методы внедрения терминов 1. Сопровождать термины пояснениями в устной речи и ссылками на глоссарий - в письменной 2. Устраивать презентации Это не смешно!
- 25. Опасайтесь конкурентов Термины-конкуренты - слова, которые проникают в речь и вытесняют правильные термины. Способы борьбы с конкурентами: 1. Быть строгим к себе 2. Поправлять коллег 3. Если ничего не помогает - заменить термин
- 26. Отношение коллег Либералы легко соглашаются на введение жаргона и расширение словаря Консерваторы сопротивляются новым терминам При внедрении опираться на либералов Не поддаваться влиянию консерваторов
- 27. Выводы по части 2 1. Необходимо обращать внимание на словарный дефицит. 2. Чем лучше подобраны термины, тем больше эффекта они приносят. 3. Чтобы жаргон "жил", нужно заниматься его распространением (внедрением). 4. Жаргонные слова приходится запоминать. Участники проекта по- разному оценивают целесообразность этих усилий.
- 28. Спасибо за внимание! Сергей Оводов, М13 so@m13.su, osa777@gmail.com
Editor's Notes
- Здравствуйте. В своем докладе хочу рассмотреть такое понятие как внутрипроектный жаргон, рассказать об опыте использования на примере нашей компании.
- Компания называется "М13", наш профиль - системы мониторинга СМИ и соцсетей. Компания относительно небольшая, работа ведется силами нескольких команд, в составе каждой из них - разработчики, аналитики, тестировщики. Построен итеративный процесс. Мы применяем объектно-ориентированный анализ. Особое внимание уделяется именованию всевозможных объектов, атрибутов, связей, действий. Набор терминов, который возникает в результате этого процесса, называется жаргоном.
- Существует жаргон профессиональный, например в IT ходят слова: “клава”, “сервак” и т.д. Жаргон проектный - это некий лексикон, который позволяет упростить общение и даже снизить количество ошибок. Примерно то же, что “глоссарий”, но слово “жаргон” подчеркивает применение слов из этого глоссария в устной речи.
- Как же помогает жаргон? Разберем несколько примеров.
- Представим, что мы разрабатываем интернет-магазин, но термин "корзина" нам по каким-то причинам не доступен. Не добавляя никаких новых понятий попытаемся описать сценарии. Система копирует список выбранных для покупки товаров в заказ и очищает список выбранных для покупки товаров - видим, что получается довольно громоздко и неудобно.
- Допустим, аналитик решил устранить нагромождение и ввел аббревиатуру. Аббревиатура - уже элемент жаргона. Текст сразу получился более компактным, но стало трудно читать и произносить: СВДПТ.
- А вот тот же сценарий, но с использованием термина “Корзина”. Сравните, насколько текст легче воспринимается и читается. Жаргон интернет-магазинов давно вышел за пределы одного проекта. Нам кажется, что слово “корзина” всегда существовало, что оно естественно. На самом же деле, если проект не является типовым, то громоздкие речевые конструкции - далеко не редкость. И они не заканчивается в одном сценарии и даже во всех требованиях вместе взятых. Впоследствии эти длинные словосочетания будут возникать на согласовании документов, в обсуждениях, в описаниях дефектов. Представьте, насколько можно сократить объем передаваемой информации вводом лишь одного термина.
- Рассмотрим ещё один пример. Разрабатывается система online-банкинга. В рамках этой системы вводится сервис “специальных клиентских именованных счетов”. Имеем следующие требования специальный клиентский именованный счет может иметь название, может быть открыт только из интернет-банка, на остаток начисляются проценты Снова видим нагромождение.
- Теперь попробуем ввести аббревиатуру: СКИС. Объем текста сразу сократился на 20%. Данная аббревиатура хорошо произносится, мы можем её использовать в устной речи. При активной работе над проектом введенный термин СКИС будет звучать десятки раз в день. Представьте, насколько это удобнее, чем 4 слова.
- Однако термин СКИС имеет минусы. Он не ассоциируется с банковским счетом и из-за этого плохо запоминается. СКИС плохо подходит для банковской отрасли. Если случится, что термин проскочит в процессе общения со службой сервиса, то клиент не обрадуется, услышав, что его счет "скис". По факту был выбран термин "цель", это абсолютно реальный продукт, он так и называется “мои цели”. Это слово прекрасно ложится в объектную модель. Фраза "клиент перевел средства на цель" легко воспринимается. Вывод - жаргон действительно позволяет упростить общение, а, следовательно, повысить эффективность работы.
- Следующие примеры о том, как жаргон поможет избежать ошибок. Представим, что разрабатывается система трекинга задач под названием “Карусель”. Система аналогична Jira, Bugzilla и прочим. Всем известен принцип работы этих систем: жизненный цикл задач описывается набором статусов и возможных переходов между ними.
- Для системы Карусель введем следующие бизнес-объекты: Задача - реализация новых требований, новая функция; Баг - запрос на исправление ошибки или противоречия в системе. Одно из требований к Карусели звучит так: На экране "планирование" должны отображаться все задачи, включенные в очередную итерацию. В таком виде требования поступили разработчику, он их реализовал. Но на тестировании выяснилось, что на экране “планирование” по факту отображаются не только задачи, но и баги. Тестировщик вернул сборку. Почему так вышло?
- В самом начале примера, мы употребили термин задача, как обобщение всех бизнес-объектов. Мы говорили, что Карусель - это система трекинга задач. А далее, в глоссарии, то же слово “задача” уже обозначало частный случай. Это в итоге привело к ошибке.
- Давайте заменим конфликтующий термин “задача”. Можно использовать аббревиатуры, либо жаргонный словарь показанный на экране. Базовый бизнес-объект системы - талон. Баг - талон на исправление дефекта, фича - талон на реализацию новых требований. Стало намного понятнее. Фраза “должны отображаться все фичи” исключает разночтения.
- Четвертый пример. Мы разрабатываем систему мониторинга СМИ, поставляем её нескольким компаниям в виде сервиса, а база пользователей при этом единая. Каждый пользователь относится к одной компании. Имеется модуль оперативного информирования, оператор может в рамках своей компании отправить некоторым выбранным пользователям уведомления. Т.е. отправитель и все получатели уведомления должны относиться к одной компании.
- Возникла проблема. Оказывается, наши клиенты часто являются партнерами друг друга и хотят иметь возможность в рассылку включать избранных пользователей из других компаний. Для решения этой проблемы мы изменили модель. Теперь каждый пользователь работает в одной компании и может быть связан с несколькими другими компаниями, чтобы из этих связанных компаний он мог получать уведомления. Это разные по смыслу отношения. Формулировка ограничения осталось прежней: отправитель и все получатели уведомления должны относиться к одной компании. Модель была реализована, при тестировании обнаружилось, что для выбора получателей по факту доступны только пользователи которые работают в компании отправителя, а те, кто связан, не доступны. Сборка в итоге была возвращена на доработку. В данном примере была допущена та же ошибка, что и в предыдущем. В терминах первой версии модели пользователь “относится” только к одной компании, а во второй версии модели слово “относится” использовалось как обобщение двух видов связей. Возникла неоднозначность, и разработчик выбрал тот вариант, который ему показался более логичным.
- Этой ошибки бы не возникло, если бы сразу использовался жаргон. Например, для данного случая, можно ввести термины: сотрудник, партнер, адресат. Когда говорится, что все получатели должны являться адресатами одной компании, разночтений быть уже не может.
- Итак, использование жаргона упрощает восприятие. Попробуйте убрать спецтермины на своем проекте и убедитесь, что работать станет значительно труднее. Жаргон позволяет снизить количество ошибок. В то же время, нельзя использовать первый попавшийся термин, это может привести к разночтениям. То есть, формирование жаргона - это всё же работа.
- И мы плавно переходим ко второй части, “Практика формирования жаргона”
- Рассмотрим предпосылки добавления нового понятия в жаргон. Словарным дефицитом назовем ситуацию, когда для продолжения работы необходимо внедрение нового термина. На слайде перечислены некоторые симптомы, которые позволят обнаружить словарный дефицит.
- При возникновении словарного дефицита нужно где-то взять новые термины. Начать стоит с поиска. Часто обращения к предметной области достаточно, чтобы решить все проблемы. Далее аббревиатуры. Забавно, что расшифровка аббревиатур часто забывается, например лично я не помню как расшифровать КАСКО, но смысл этого термина мне остается понятным. Это значит, важно само понятие, а не его формальное наименование. Следующий метод - транслитерация. При копировании английского произношения у слов как бы появляется новый смысл (например слова “скролл”, “релиз” или “скриншот”). Это позволяет повысить точность жаргона Наконец, метафора. Термины, полученные посредством хорошей метафоры, приживаются легче всего.
- Чем лучше подобраны термины, тем больше пользы. Далее некоторые критерии качества терминов. Самый важный критерий - однозначность. Известно, что если на этапе анализа допущена ошибка, то её исправление на более поздних этапах существенно дороже. Неоднозначность - это причина многих ошибок. Особенно важно, чтобы не возникало конфликта между спецтерменами и общеязыковыми словами. То есть, хороший спецтермин должен сам говорит о том, что он спецтермин.
- Очевидно, что произносимость - один из важнейших критериев, поскольку мы говорим об упрощении речи. Следующий критерий - интуитивность - мера того, насколько термин понятен человеку сходу, без изучения глоссария. Далее - согласованность. Корзина, например, по смыслу - это некий контейнер, поэтому возможен оборот "положить товар в корзину". То есть, термин “корзина” согласован с термином “товар”. Следующий критерий - стиль. Жаргон имеет свойство выходить за рамки проектной команды. Термины сразу лучше выбирать так, чтобы они подходили по стилю разрабатываемому продукту и ни у кого не вызывали раздражения. Замечу, что термины, которые удовлетворяют всем критериям, удается найти очень редко, да и в большинстве случаев на это попросту нет времени. Поэтому приходится чем-то жертвовать.
- Чтобы глоссарий превратился в настоящий жаргон, его не достаточно где-то один раз записать. Термины должны жить, то есть, использоваться в общении, в переписке, в документах, даже в пользовательском интерфейсе. Для того, чтобы этого добиться, предлагаем следующие практики (на экране). Сопровождать термины пояснениями, ссылками на глоссарий, устраивать презентации глоссария. Отдельно остановимся на 3 пункте - термины-конкуренты. Ещё один важный момент. На ранних этапах появления спецтермины могут казаться смешными и вульгарными. Но, поверьте, это только первое впечатление. После дня активной работы никакой жаргон уже смеха вызывать не будет, и улыбка будет возникать только у консерваторов или коллег, не работающих по проекту.
- Если правильный термин из глоссария не удобен, то него может появиться конкурент. В примере про “Карусель” предлагался термин Талон, это возможно не самый изящный вариант. В разговоре с новым человеком на проекте проще сказать “задача”, хотя вы знаете, что это не соответствует принятому глоссарию. Промелькнуло в разговоре, переписке и, наконец, попало в документацию. Последствия такие же, как и при отсутствии глоссария: появляются разночтения, повышается риск возникновения ошибок. На слайде перечислены возможные способы сопротивления конкурентам, и пункт №1 - внимательность и строгость к себе.
- Далее про человеческий фактор. Один из минусов использования жаргона в том, что его приходится запоминать. Коллеги по-разному могут оценивать оправданность этих усилий. Условно их можно поделить на либералов и консерваторов. Либералы - те, кто легко соглашаются на расширение жаргона, как правило это люди, которые непосредственно участвуют в разработке, и много общаются по тематике проекта. Консерваторы - наоборот, сопротивляется каждому новому термину, пытаются обходиться естественным языком. Как правило, к ним относятся лица, работающие с клиентами или на нескольких проектах. Чтобы термин начал оживать важно найти единомышленников которые начнут его первыми использовать и искать из разумно среди либералов. Что делать с консерваторами? Быть непреклонными, использовать предложенные методы внедрения, и при общении с ними не поддаваться влиянию.
- На экране выводы по 2 части. В заключении хочу сказать, что в пользе описанного подхода убедился неоднократно. Использование жаргона требует определенных усилий, но чем лучше подобраны термины, тем легче они принимаются, дольше живут, шире распространяются и больше приносят эффекта. Вопрос с первого взгляда кажется простым, но я подошел к нему чуть более формально и получилось, что жаргон - это полноценный инструмент анализа.