что такое скоуп вопросов
Скоупы — PHP: Eloquent (ORM)
Чем больше становится проект и чем сложнее его логика, тем чаще возникает потребность в построении запросов с условиями, группировками и сортировками. В коде проекта все чаще начнёт возникать подобный код:
Иногда такие запросы могут встречаться прямо в обработчиках запросов. Но если начать ими злоупотреблять, то код постепенно начнёт превращаться в кашу.
Проблем здесь несколько. Не все условия могут быть очевидны. Например, что такое 100 в примере выше? Почему именно 100? Магическое число. Кроме того, если это число имеет какое-то особое значение, то вероятно оно будет встречаться и в других обработчиках точно в таком же запросе. Это значит что произойдёт дублирование.
Некоторые части запроса могут иметь значение только тогда, когда они встречаются вместе и их нужно указывать всегда. Например, выше мы выбираем только активные посты, у которых больше 100 просмотров. Можно предположить, что эти два условия связаны между собой, возможно в этом запросе подразумевается поиск «популярных постов». Это значит, что в любом месте где нам понадобятся популярные посты, нужно не забыть скопировать эти два условия.
Для решения этих проблем нужно повышать уровень абстракции – создавать функции, которые прячут в себе эти детали. Их можно сделать самостоятельно, но Eloquent уже имеет встроенный механизм называемый скоупами (Scope).
Его принцип работы крайне прост. Каждое условие или набор условий, которые мы бы хотели как-то обозначить функцией, можно задать в виде скоупа. Скоуп в терминах ORM и есть функция, которая определяется прямо в модели и используется фреймворком при построении запросов:
Каждый скоуп — это обычный метод, который начинается с префикса scope. Именно по префиксу Eloquent понимает, что это скоуп. Внутрь скоупа передаётся запрос, на который можно навешивать дополнительные условия. Результатом работы любого скоупа должен быть скоуп.
Далее они становятся доступны как и любые другие методы языка запросов:
Скоупы можно вызывать из скоупов. Это помогает снизить уровень дублирования при построении более сложных запросов. Например, если мы считаем, что популярность оценивается только среди активных постов, то это легко поправить, изменив соответствующий скоуп:
Динамические скоупы
SCOPE проекта
Рассмотрим такую ситуацию, приходишь ты весь такой замотивированный на результат к своему руководству и говоришь: «У меня есть идея продукта!» и начинаешь красиво излагать свои мысли. Тебя выслушали, не всё поняли, ну а другого исхода ожидать и не стоило, ведь ты даже не поинтересовался о наличии времени.
Руководитель смотрит на тебя и говорит: «Сделай scope проекта!»
Когда я в первый раз услышал «Сделай scope проекта» меня одновременно охватила чувство восторга, ведь мою идею не проигнорировали, но в то же время появилось чувство тревоги, так как никогда раньше я не сталкивался с подобным.
Поиски информации про scope и его примеров в интернете дали не конкретное, но примерное представление что это и как это разработать.
Дело в том, что примеров адекватных мало, а также, каждый найденный мною пример, представлял что-то совершенно отличное от предыдущего, от чего в голове все больше образовывалось каша.
Чуть позже я вспомнил про книгу «Разработка требований к программному обеспечению», которая помогла мне сориентироваться в разработке SCOPE проекта, рекомендую её к прочтению!
Инструкция по созданию scope (концепции) проекта
Давайте разберем создание концепции на примере онлайн-сервиса предзаказа кофе.
Крупная федеральная сеть кофеен «Моя кофейня» обратилась в студию разработки востребованных продуктов «Product Architect Guide» с просьбой оценить потенциал и готовность рынка к онлайн-сервису предзаказа кофе на территории Российской Федерации и разработать такой продукт, если результаты исследований окажутся положительными и удовлетворят руководство сети кофеен «Моя кофейня».
Оценка рынка кофе в РФ
Исследуем рынок кофе на Родине. Ищем информацию и данные на предмет:
— объёмов и структуры потребления кофе.
Анализируем найденный контент и перекладываем свои мысли в концепцию, не забываем указать риски и сделать выводы.
Развернуто отвечаем на вопросы:
— Какую проблему решаем?
— Зачем нужен онлайн-сервис предзаказа кофе?
— Для кого мы его делаем?
— Что онлайн-сервис даст тем, для кого мы его сделаем?
— Что из себя онлайн-сервис будет представлять?
— В чем его преимущества?
— Где уникальность онлайн-сервиса?
Ответив на все указанные вопросы, мы рассказали основную идею проекта.
Не забываем, что заказчик тоже человек (или группа лиц) и может забыть донести важные глобальные цели проекта.
Занимаем проактивную позицию и превосходим ожидания заказчика: указываем глобальные цели проекта.
Если заказчик посчитает указанные цели слишком амбициозными, то мы всегда сможем внести правки в документ.
Выбираем кофейни сети, в которые мы пойдем проводить опрос гостей и персонала.
Фиксируем результаты и делаем выводы.
Рассказываем про возможности работающего бизнеса, которые нам необходимо учитывать при разработке сервиса.
Фиксируем бизнес-цели по формуле:
Рассказываем про бизнес-риски от внедрения сервиса, т.е. какие негативные последствия для бизнеса могут появится после внедрения сервиса в «боевую» эксплуатацию.
Анализируем и рассказываем о преимуществах использования сервиса для рядового гостя и заведения.
Рассказываем про функциональные возможности сервиса.
Указываем роли и зоны ответственности в команде разработки сервиса, а также профили заинтересованных лиц.
Если требуется дополнительная декомпозиция концепции проекта, то достаточно будет расписать:
— критерии успешности проекта;
— архитектуру информационной системы и её отдельных элементов;
— описание элементов системы и их взаимодействия;
— стратегию управления проектом;
— совокупную стоимость владения сервисом;
— схему внедрения сервиса.
Полное описание концепции можно скачать в новом Telegram-канале
Так все хорошо начиналось, чтобы кончиться телеграмм каналом
И, правда, дичь какая-то.
напоминает «отправь sms с содержанием 911 на короткий номер 911, чтобы скачать рингтон Верки Сердючки»
Если захотелось бы автору, чтоб скачали, то дал бы ссылку нормальную
А там было хорошее начало? 🙂 Мы что-то пропустили? Неструктурированная и местами нелогичная банальщина от копирайтера для продвижения ТГ-канала
Говорить о неструктурированности и нелогичности без конструктивной критики, это я смотрю у тебя норма:)
Вам примеры нужны? Легко. На шаге «Оценка рынка» ничего не сказано про анализ конкурентов. Ничего не сказано про прайсинг и про промо продукта/сервиса, забыли про финмодель вообще. И такого можно много надергать. Это грубейшие фундаментальные ошибки, так что текст явно писал кто-то, кто подобными вещами не занимался. Видны уши копирайтера, который за часик прочитал по диагонали данные ему источники и написал, как понял.
Без обид, но меня удивляет Ваше нежелание глубже проанализировать статью. Как я и говорил в комментарии ниже, которому вы поставили «-», что негатив в комментариях идёт от людей, которые хотят сразу все готовенькое на блюдечке. С шагом 2 ознакомьтесь. Автор статьи все правильно рассказал, в том числе обобщил главное, если Вас не устраивает, что Вам весь материал от и до не разжевали, так зачем критиковать? Может быть какие-то детали специально не доведены до аудитории. Обратитесь к автору с просьбой уточнить подробнее интересующие Вас моменты. Нет идеальных людей, продуктов и вообще ничего идеального нет, подумайте о том, что Вы что-то не так поняли или не знаете. Лично у меня принцип такой: я благодарю человека за потраченное время и силы, а если мне что-то не ясно капаюсь самостоятельно, и если не могу найти ответ, то обращаюсь с вежливой просьбой объяснить.
С шагом 2 ознакомьтесь
1. И что я увижу на шаге 2? Он там ценообразование продукта сделал? Финмодель построил?
2. Вопрос не в «хотят готовенькое», а в том, что автор позиционирует себя экспертом в данном вопросе. А на самом деле выясняется, что фундаментальные вещи он упустил. Написал учебник по арифметике, сложение и вычитание упомянул, а про умножение и деление забыл. А теперь Вы говорите, что это не учебник дерьмовый, а автор специально так задумал, чтобы дети сразу всех знаний не получили. Ога, прям сразу верится.
Крупная федеральная сеть кофеен «Моя кофейня» обратилась в студию разработки востребованных продуктов «Product Architect Guide» с просьбой оценить потенциал и готовность рынка к онлайн-сервису предзаказа кофе
Если бы Apple проводила подобную оценку, то первый iPhone был бы кнопочным)
Как человек, который разрабатывал концепции, я понимаю что это такое и сколько сил и времени нужно вложить в разработку документа. Те, кто здесь кричит о банальщине, неструктурированности и о том, что не правильно связывать продвижение собственного ресурса со статьей, в моем представлении люди, которые лишний раз доказывают, что не терпят, когда им не приносят все на блюдечке. Наверное такие мыслят так: «Ага, что-то новенькое, где это взять? Ах, тут надо лишний раз куда-то перейти, да ещё и в тг-канал. автор нахал и самодур, как он себе такое позволяет? Не мог что ли ссылку нормальную дать на скачивание. Да и мне как-то индифферентно на автора и его время, я вообще просто поболтать тут в комментах люблю.»
Платформа подключена к онлайн-сервису Figma.
Не говори красиво, говори правильно. или Глоссарий управления проектами
Начнем эту заметку с рассказа об одном забавном эпизоде. Однажды в нашей компании проходили практику студенты-дипломники, специализирующиеся на управлении проектами.
 |
| Григорий Львович Ципес, ведущий системный аналитик компании IBS, GTsipes@ibs.ru Александр Самуилович Товб, руководитель проектов компании IBS, A_Tovb@ibs.ru |
Начнем эту заметку с рассказа об одном забавном эпизоде. Однажды в нашей компании проходили практику студенты-дипломники, специализирующиеся на управлении проектами. Выдавая им задание, руководитель практики (один из авторов этой заметки) попросил описать scope проекта (он так и сказал — скоуп). «А что такое scope?» — осторожно поинтересовалась одна девушка. «О, scope — это. » — ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. «Понятно, — грустно сказала девушка. — Нам в институте так же объясняли».
Ситуация очень характерная и довольно опасная. Есть некий термин, употребляемый в англоязычных источниках и не имеющий очевидного и однозначного перевода на русский язык в контексте управления проектами. На профессиональном жаргоне мы привыкли пользоваться этим термином на языке оригинала. Действительно, гораздо удобнее сказать scope, чем какое-нибудь достаточно громоздкое «содержание и границы». Если кому-то непонятно, то всегда можно объяснить, хотя бы с помощью жестов. А приводит все это к тому, что некоторое время спустя точного значения термина никто уже не помнит, каждый трактует его по-своему, и при этом все думают, что понимают друг друга!
Прибавьте к этому еще и то, что и на языке оригинала многие термины трактуются вовсе не однозначно. В сравнительном словаре Макса Вайдемана [MW], опирающемся на более полусотни источников, для многих терминов приводится по 5-6 различных определений. Русскоязычные глоссарии, которых тоже набирается немалое количество, во многих случаях запутывают ситуацию еще больше.
Теперь взглянем на эту проблему с точки зрения стандарта управления проектами. Стандарты — это документы, которые не должны допускать различных трактовок и которые должны быть понятны каждому сотруднику предприятия. Из этого следуют, по крайней мере, два вывода, существенные для темы нашей заметки. Во-первых, стандарт должен содержать определения основных используемых терминов, и, во-вторых, эти термины не следует применять ни на английском языке (хотя упоминание английского аналога, безусловно, полезно), ни в их транслитерации на русский язык.
Авторы стандарта вольны решать, каким путем они пойдут при формировании глоссария — подберут ли готовые определения на русском языке, сделают ли собственный перевод с английского или, может быть, предложат свои определения, адаптированные к профессиональной среде и квалификации персонала предприятия. Очевидно одно, в любом случае задача эта не будет простой.
Приводя в этой заметке небольшой глоссарий, мы ни в коей мере не претендуем ни на полноту, ни на анализ или критику включенных в него определений. Единственная его задача — дать объяснение терминам, которые мы использовали в наших заметках, и соотнести их с часто употребляемыми аналогами.
КРАТКИЙ СРАВНИТЕЛЬНЫЙ ГЛОССАРИЙ
Источники, по которым цитируются определения:
Поделитесь материалом с коллегами и друзьями
Словарик айтишника или Что? Где? Куда? Часть 1
«Привет! Добро пожаловать! Спасибо, что приняла наш оффер. Пойдем знакомиться с твоей командой. У них как раз сейчас дейли. Ты вышла под конец спринта, поэтому пока работы для тебя не запланировали. Как стендап закончится, можешь почитать спеки, командные окиары и просмотреть бэклог на следующий спринт. По всем вопросам обращайся к своему пио.»
Язык айтишников
Каждый, кто работает в IT, непременно сталкивался с профессиональным жаргоном и компьютерным сленгом. Его можно любить или ненавидеть, принимать или терпеть, но непреложным остается факт — IT-жаргон существует и от него никуда не деться.
Когда приходишь в новую компанию, на тебя наваливается куча незнакомых слов. Кажется, их так много, что потребуется немало времени, чтобы понять и выучить их все. Многие слова ты уже знаешь, о смысле других догадываешься, часть из них является англицизмами, поэтому догадаться об их значении несложно Первая реакция — неприятие: «Зачем использовать английские слова в русский речи, когда есть достаточно русских альтернатив?» Потом ты пытаешься сохранить чистоту языка. В итоге, начинаешь говорить так же, как и все. Это неизбежно.
Профессиональный жаргон существует не для того, чтобы испортить русский язык. Он позволяет ускорить устное общение IT-специалистов и наладить их взаимопонимание. Обычно слова получаются короткими и емкими. Иногда одно слово заключает в себе целую фразу. Поэтому польза в них, на мой взгляд, есть.
Я послушала, как говорят разработчики в Wrike, и составила словарик из самых распространенных слов. Слова собраны по тематическим группам.
Scrum-терминология
Scrum — это методология по управлению проектами. Набор принципов, ценностей, политик, ритуалов для организации работы. В скраме полно терминов, но в ежедневный обиход попала и закрепилась только часть из них.
Бэклог
От англ. backlog (дословно — очередь работ) — еще не запланированный объем работы, который требуется выполнить команде. Каждая созданная задача вначале попадает в бэклог, а потом уже в спринт.
Как и в случае со спринтом, термин используется и в отрыве от скрама. Часто бэклогом называют отложенные задачи. Которые сделать нужно, но не сейчас.
Гол, голевой
От англ. goal (дословно — цель) — цель спринта (бывает одна или несколько), которую команда берется сделать. Цель состоит из ряда задач, которые нужно выполнить, чтобы его достигнуть.
Слово употребляется и как существительное, и как прилагательное. Может быть множественного числа.
Дейли
От англ. daily (дословно — ежедневно) — ежедневные короткие (от 5 до 30 минут) встречи команды с целью поделиться прогрессом по выполненным задачам за предыдущий день и озвучить план работ на текущий день. Также дейли могут называть стендапом (от daily standup), потому что обычно такие встречи происходят стоя — для большей эффективности.
Коммититься
Глагол от англ. существительного commitment (дословно — ответственность). Коммититься — значит обещать выполнить определенный объем работы в оговоренные сроки. Это не просто обещание, это сознательное обязательство перед собой и командой. Человек, который закоммитился, обязан сделать всё возможное, чтобы выполнить то, что сам и пообещал реализовать.
Спринт
От англ. sprint (дословно — бег на короткую дистанцию) — заданный отрезок времени, за который нужно выполнить запланированный объем работы, чтобы в конце этого отрезка был ожидаемый результат.
Термин используют не только те, кто работает по скраму, но и те, кто просто хочет организовать свою работу и сформировать ясные рамки, во время которых должны быть выполнены задачи.
Инструменты для работы
Технические, информационные и вспомогательные средства и приложения для работы.
Ветка
От англ. branch (дословно — ветка) — тот редкий случай, когда в ходу русский перевод термина. Веткой (термин git) называют полную копию проекта, в которой ведется разработка. В проекте может быть создано много веток, что позволяет работать одновременно с разными частями кода. Потом все ветки загружаются в мастер. Процесс «ответвления» иногда называют «бранчеванием», уже как раз от branch.
От англ. mock-up (дословно — эскиз) — макет с UX-дизайном для разработки. Несмотря на то, что слово дословно переводится как «эскиз» или «прототип», в Wrike моками называют готовые проработанные макеты с дизайном.
От англ. production (дословно — промышленная среда) — ветка с рабочей версией продукта, которую видят пользователи. Это окончательная точка куда попадает результат разработки. Иногда так же называют мастер.
От англ. reference (дословно — пример) — схожий функционал или внешний вид, который используется для ориентира. Он служит для сравнения.
Спека
От англ. specification (дословно — спецификация) — документ с подробным описанием требований, условий и технических характеристик, как должен работать разрабатываемый функционал.
Таска
От англ. task (дословно — задача) — задача, заведенная или планируемая на любого работника.
Разработка
Термины, употребляющиеся разработчиками при работе над задачами.
От англ. boost (дословно — ускорение) — процесс повышения производительности, ускорение загрузки.
Катить
Отправлять готовую работу в деплой, предпринимать шаги для подготовки ветки к мерджу в продуктовую ветку.
Комплитить
От англ. complete (дословно — заканчивать) — завершать задачу, закрывать задачу, когда она полностью готова.
Консистентность
От англ. consistency (дословно — системность) — общее единообразие во всех частях продукта.
Матчится
От англ. match (дословно — совпадать) — полное соответствие чего-либо с чем-либо. Процесс приведения к единообразию.
Пинать
Термин, подобный глаголу «пинать», который также имеет значение «делать» и «работать». Конкретное значение определяется по приставке. Подопнуть — сделать немного, допинать — доделать.
Ручка
От англ. handler (дословно — обработчик) — бэкэнд-термин, означающий ответ от сервера, в котором приходят данные.
Скоуп
От англ. scope (дословно — объем) — набор фич и частей продукта, закрепленных за отдельной командой.
От англ. feature (дословно — характеристика) — определенная часть или деталь от общего продукта, которая разрабатывается изолированно.
От англ. flow (дословно — течение) — порядок действий при работе над задачей. Например, вначале задача берётся в разработку, потом проходит ревью, далее тестируется и т.д.
Должности
Некоторые должности, названия которых вошли в обиход в виде сокращений с английского.
Девопс
От англ. DevOps, сокращенно от Developer Operations (дословно — интеграция разработки и эксплуатации) — специалист, занимающийся внедрением DevOps-методологии. Полное название должности — DevOps-инженер, но в речи вторую часть всегда отбрасывают.
От англ. PO, сокращенно от Product Owner (дословно — владелец продукта) — роль по скрам-методологии, человек, ответственный за проработку продукта и распределение бэклога. Он знает о требованиях пользователя и возможностях команды.
От англ. PM, сокращенно от Product Manager (дословно — менеджер продукта) — менеджер, который отвечает за продукт, его обязанности совпадают с обязанностями пио, отличие только в том, что это название должности, а не роли в скраме. Так же, как пио, пиэмов могут называть продакт.
Организационное
Термины, относящиеся к организации работы, а также термины, употребляющиеся в неформальной речи при обсуждении чего-либо.
Дейоф
От англ. day-off (дословно — выходной) — просто выходной.
Драйвер
От англ. driver (дословно — водитель) — человек, который берет на себя инициативу управления проектом/процессом/задачей. В его обязанности входит следить за тем, как протекает созданный им процесс, и руководить им. Он мотивирует других людей выполнять работу для достижения поставленных целей.
Консёрн
От англ. concern (дословно — тревога, участие) — в английском языке слово «консёрн» имеет много различных значений, при этом очень часто употребляется в русской речи. Какое именно значение вкладывает в него автор, известно только ему самому. Иногда — это смесь многих значений, таких как: особый интерес, беспокойство, цель, настороженность, опасение и т.д.
Окиары
От англ. OKR, сокращенно от Objectives and Key Results (дословно — цели и ключевые результаты) — система по постановке и достижению целей. Она нужна для синхронизации работы всех участников компании/отдела/команды, чтобы все двигались в одном направлении, с понятными приоритетами и постоянным ритмом. В отличие от KPI, это амбициозное целеполагание, достижение окиаров (окров) на 70-80% — отличный результат.
Оффер
От англ. offer (дословно — предложение) — предложение о работе / приглашение на работу.
Поинт
От англ. point (дословно — точка) — чаще всего употребляется в значении «точка зрения», сокращенно от point of view. Также в значениях: «суть», «смысл», «довод».
Зоны ответственности в проекте
Вопрос границ и зон ответственности сам по себе глобальный. Для человека, например, формирование личных границ является этапом взросления и становления личности.
Но если посмотреть на границы в контексте IT-проектов, то окажется, что из-за не самых качественных границ регулярно возникают проблемы. Они приводят к чему угодно: от потери ценных кадров с негативным фидбеком о работе в компании до провала проектов.
Ниже попробую порассуждать, когда с этими проблемами сталкиваются, предложу пример из опыта и вариант фиксации границ зон ответственности.
Когда начинаются проблемы границ
В проектах автоматизации присутствует примерно одинаковый набор функциональных задач. На начальных этапах проекта или в маленьких компаниях и командах есть один-два-три человека, которые делают работу, начиная управлением продукта и маркетингом, заканчивая full stack разработкой. И работают без жалоб, при этом решая вопросы общением.
Со временем наступает ситуация, когда приходится заняться расширением команды, например:
Уровень зрелости решения достигает необходимости повышения качества отдельных функций
Людей перестаёт хватать, чтобы делать функции самостоятельно
Возникает потребность в полноценном выполнении некоторых функций, которые делались по совместительству
И тогда команда сталкивается с проблемами роста:
Слишком много времени начинает уходить на взаимодействие, встречи забивают календарь, а работать некогда
Возникают конфликты и жаркие споры при решении тех или иных вопросов
Одну и ту же работу делают разные люди
Давайте на примере
Достану из чертогов памяти один пример автоматизации, на котором было не всё гладко. Начинался он как любой другой проект. Со стартом проекта выделялась небольшая команда, решение начинало потихоньку развиваться, и дела как-то делались.
С ростом проекта задач становилось больше, что привело и к увеличению команды. И начались общие претензии по качеству работы, а также конкретные жалобы на:
Менеджеров — не делали работу хорошо
Заказчиков — бесконечно меняли требования
Аналитиков — не успевали в срок
Круговорот недовольства в проекте
Итого напряжение в команде росло, в проекте менялись менеджеры, а сроки соблюдались с большим трудом. А я, как тимлид аналитики, получал негативную обратную связь от падаванов, которые жаловались на процессы и говорили, что «так работать нельзя».
При погружении в проект обнаружилась проблема — слишком много времени уходило на коммуникацию, и при этом регулярно возникали вопросы типа «а кто решил, что делаем именно так?». Эту ситуацию и попробовали решить, зафиксировав границы ролей.
Как можно распределять ответственность
Задача разделения ответственности раскладывается на следующий список подзадач:
Зафиксировать список ролей
Для каждой роли зафиксировать набор функций, за которые она отвечает
Базовым подходом для решения такой задачи можно считать RACI-матрицу. Концептуально список ролей не зафиксирован жестко и может быть различным, но базовыми считаются:
Responsible — Исполнитель, ответственен за некоторый участок работы, который доверен только ему
Accountable — Ответственный, управляет процессом или является его владельцем
Consulted — Эксперт, обладает экспертизой в том или ином вопросе
Informed — Информирующий, обладает информацией по процессу, может косвенно влиять на результат
Но если попытаться применить эту модель, то у неё всплывают свои минусы: с одной стороны, слегка избыточна и сложна для построения, с другой — недостаточно атомарна, чтобы явно обозначить набор функций, которыми занимается, например, та же аналитика:
Аналитик работает как “Исполнитель” по своим задачам
Та же аналитика, особенно лид аналитики, “Ответственна” за свои процессы
Аналитик часто “Эксперт” в тех или иных вопросах
Аналитик также “Информирующий” по вопросам взаимодействия внутри команды
Альтернатива
Если всё-таки отталкиваться от функций, то у них есть:
Ответственный — один конкретный специалист или некоторая роль, которая отвечает за финальный результат
Все остальные — в силу своей заинтересованности могут так или иначе влиять на результат
Получается следующее представление границ каждой функции:
Круги ответственности
Зона ответственности — та часть деятельности, за которую ответственен именно специалист. Чтобы реально что-то менять и чем-то управлять, та или иная функция должна быть именно в этой зоне
Зона влияния — область, которая находится рядом с зоной ответственности специалиста. Здесь специалист может советовать как эксперт или просто о чём-то информировать, задать любой вопрос и предложить любой новый подход, не неся при этом финальной ответственности
Зона смирения — область, в которой нет рычагов влияния. Сюда попадают, если все попытки повлиять на что-то исчерпаны, и больше вариантов нет. Здесь есть две опции — «понять, принять и смириться» или «уйти» из проекта или из компании.
Подход кажется удобным, если список функций и ролей известен. Например, в компаниях, где есть более-менее устоявшиеся процессы. Для каждой функции определяется ответственный, а все остальные роли при наличии желания могут пытаться влиять на выполнение функции и на процессы.
И получается вполне прозрачный механизм. Если хочется что-то изменить, то вариант один — сделать это своей зоной ответственности.
Так что с примером?
Если вернуться к примеру с этими зонами, то:
Проверили, что участники команды понимают существующие роли в проекте
Для каждой роли зафиксировали список функций, за которые эта роль ответственна
Договорились, что остальное — зона влияния, где каждый может что-то пытаться делать, но финальное решение не принимает и ответственность не несёт
Имели три конфликтующие проектные роли — аналитика, проектный менеджмент и заказчик.
Сначала поговорили с аналитиками. Они, согласно предыдущей статье «Аналитик в автоматизации — кто он и чем занимается», специалисты широкого спектра. Поэтому, если упростить, зафиксировали, что аналитика занимается:
Фиксацией разных требований и ограничений
Формализацией, проектированием и оптимизацией бизнес-процессов
Разработкой моделей данных (ER-диаграмм)
Разработкой различных постановки задач или спецификаций
Дальше менеджеры. Мы жёстко разделили роли аналитики и менеджера. И поэтому в зоне ответственности менеджера остались вполне себе стандартные менеджерские вопросы, на которые заказчик и аналитика могли влиять:
Формирование проектной команды
Организация процессов взаимодействия
Фиксация скоупа проекта и приоритетов задач
Фиксация и отслеживание сроков
Организация работы людей в проекте
Ну а заказчик был определён и зафиксирован как участник, который несёт ответственность за продукт. За ним финальное решение о том, куда пойдёт продукт. Аналитик, как эксперт, влияет на продукт — предлагает новые фичи, рекомендует различные подходы и тенденции.
Что получилось?
Нормально расставленные и зафиксированные границы — штука хорошая. Даже если кто-то один так себе границы соблюдает, остальные участники команды помогают процессу работать верно.
В итоге, пообщавшись и договорившись по задачам, удалось перевести работу в нужное и продуктивное русло:
Прекратилась передача задач и приоритетов напрямую заказчиком в аналитику
Менеджер смог делать свою работу и управлять заказчиком, его бэклогом, сроками и ожиданием
Заказчик получил свои (корректные) рычаги влияния на задачи
Аналитики знают, что должны сделать, если видят проблему и хотят что-то изменить в решении или в процессах
Исправилось взаимодействие аналитики и менеджмента — исправилось и остальное
Так же сделали и с другими ролями в проекте, например, с дизайнерами, разработчиками, тестированием. И главное, чтобы границы не ломались, договорились до следующего:
Новеньких сразу обучаем принятым границам между ролями
Поощряем работу в зоне влияния, поощряем эскалацию
На периодических со специалистами встречах собираем обратную связь и, при необходимости, вносим точечные правки
И общий профит
На уровне выше конкретного проекта также есть профит соблюдения общих границ. Например, для нас, как для компании-интегратора:
Упрощается запуск проектов, так как проекты работают по одному шаблону
Проектную команду расширять легче, так как исключается длительное погружение в процессы конкретного проекта
Ротация сотрудников между проектами возможна и работает
Новому человеку проще разобраться, как работает компания
Ясны границы, в которых можно влиять на процессы
Ценность сотрудника для компании не зависит от конкретного проекта
А можно без этого обойтись?
Да, можно и без таких формальных заморочек. Например, в in house, где каждый проект часто уникальная снежинка, или в небольшой команде. Как замечено в одном из комментариев к прошлой статье, в маленьких компаниях часто обходятся без аналитиков. Да и без узких специалистов вообще.
При этом важно понимать, что функции есть всегда. Просто один человек может выполнять функции нескольких ролей. И когда в команду приходит новый человек, особенно если это новая выделенная роль в команде, важно зафиксировать, чем этот человек будет заниматься и какие полномочия ему передаются.
И стоит ещё сказать, что описанный подход к разделению ответственности, наверняка не единственно верный. Сейчас пришли к этому. Может быть, через какое-то время поймём, что здесь тоже всё не так гладко. Но это не значит, что мы откажемся от фиксации функций и от того, чтобы ответственность за них делить между ролями. Просто может быть, что попилим как-то иначе.