Версия 18:50, 14 октября 2013

Серия осенних конференций началась с AgileKitchen. В конце месяца будет SECR с Иваром Якобсоном, потом — SQAdays во Львове с отдельным днем европейских докладчиков, а в начале декабря — SPMconf в Казани. Это — те, на которых я планирую быть, чтобы услышать, почувствовать новые тренды отрасли, узнать новые практики. И удачное начало этому было положено на AgileKitchen в эту пятницу, на территории Лаборатории Касперского.

Несмотря на название и позиционирование как обмен мнениями «на кухне», это было достаточно серьезное мероприятие. И по числу участников — думаю, было около сотни, хотя могу ошибаться, — которые сидели в большом зале, объединенном из трех переговорных с тремя большими экранами, и по уровню организации. И, главное — по характеру выступлений. На AgileKitchen выносятся темы, которые сейчас на острие развития, не успели обрасти серьезными теориями и практиками, но которые пробуют изучать и применять. И люди обмениваются опытом. А еще — там делятся практическим опытом решения задач, которые почему-то не становятся менее актуальными, несмотря на, казалось бы, давно известные подходы к решению. Их решают в конкретных условиях, и каждое новое решение имеет свои особенности, дает какой-то новый опыт, который тоже интересно обсудить.

Собственно, обсуждение практического опыта — самая важная составляющая мероприятия. И его было много: в перерывах между докладами, на OpenSpace, после конференции.

Мотивация и коммуникации

Обзор выступлений я на этот раз начну с темы мотивации и коммуникации, которая была темой сразу нескольких докладов.

Motivation 3.0: что вы должны знать для работы с командой (Алексей Пименов)

Алексей Пименов работает в ФИНАМ. Он рассказывал об эволюции теории мотивации и исследованиях в этой области. О том, что правильная мотивация для творческих задач, которыми занимаются ИТ-шники, возникает, когда ты находишься «в потоке». А это означает, что подходы, основанные на различных KPI и метриках, — неуместны. Что особенно интересно — он сумел рассказать это не только нам, программистам, которые «в теме». Он сумел убедить в этом не-ИТ-менеджеров у себя в компании.

Версии мотивации в изложении Алексея.

Мотивация 1.0 — нами управляют потребности. Пирамида Маслоу. Понятно, что для потребностей нужна система сдержек и противовесов, на случай противоречащих потребностей разных людей. И это ведет к следующей ступени.

Мотивация 2.0 — мы стремимся к удовольствиям, избегая наказаний. А удовольствия и наказания отмеряются, по Тейлору, в научной организации труда. Что приводит к KPI и методу Кнута и Пряника.

У этой системы есть 7 фатальных изъянов:

• могут гасить внутреннюю мотивацию;
• могут снижать эффективность;
• могут подавлять творчество;
• вытесняют хорошее поведение;
• поощряют мошенничество, поиск легких путей, неэтичное поведение. Игра SLAka — выдержать SLA у себя и скинуть так, чтобы соседи не выполнили;
• могут вызывать привыкание;
• могут развивать косность мышления.

Более того, довольно давно проводились эксперименты, показывающие, что потребности и наказания вовсе не являются единственной и даже самой сильной движущей силой интеллектуальной деятельности. И не только у человека, но и у обезьян. Эксперименты Гарри Харлоу в 1949 показали, что обезьяны разгадывают головоломки «просто так», и добавление к этому элемента вознаграждения (изюм) увеличивает результат (ускоряет разгадывание) незначительно.

Дуглас МакГрегор в 1960 году в Human Side of Enterprise ввел понятие людей двух видов: X-person, которым нужен менеджер, и Y-person, которые увлечены сами.

А в 1969 Эдвард Леси на экспериментах с людьми, аналогичных опыту Харлоу показал, что добавление материальной мотивации убивает творческий процесс, который без нее — развивается.

Так возникает Мотивация 2.1 — интегрируем в 2.0 МакГрегор.

• Рутина без Разнообразия — Деньги. Признать, что рутинная, разрешить выбрать способ для компенсации.
• Рутина с Разнообразием или НеРутина — обеспечиваем условия и работаем на самореализацию. Признание заслуг и прочее. Командное взаимодействие. А деньги всегда даем неожиданно — иначе он будет пользоваться именно этим.

Возникает вопрос — а что значит «обеспечить условия работы»? Отчасти ответ дает двухфакторная теория мотивации Герцберга — надо обеспечить гигиенические факторы. Но этого недостаточно.

В 1990 появилась работа Михай Чиксентмихайи. Мысль, что «мы проживаем жизнь неправильно». У человека есть состояние потока, в котором индивид может направлять внимание на свои цели, потому что не надо бороться с отвлечением внимания и угрозам. Состояние потока — единение с деятельностью и ситуацией. И так возникла Мотивация 3.0 — мы стимулируем участие, естественное желание работать путем переживания потока.

Правда, готовых рецептов тут нет. Речь идет об индивидуальной работе. Потому что состояние потока возможно, когда человек увлечен, а еще — когда он находится в допустимом коридоре по осям Требования — Умения. Потому что, когда Требования > Умений = Тревога, а Умения > Требований = Скука.

Но есть правила того, что помогает, и что мешает. Помогает:

• ясность в отношениях — знаете, что хотят;
• интерес руководителя, что думает и чувствует подчиненный, а не только к прогрессу задачи;
• предоставление возможности выбора и принятие ответственности за него
• чувство общности (поддержка, ценности);
• НЛП-шное якорение. Один раз войдя в состояние, повесить якорь и научиться входить туда же. Правда он не умеет, но про инструмент — знает

Agile содержит много практик, которые работают именно в этих направлениях: обратная связь, ценностная модель, совместная деятельность.

Что мешает:

• Психическая не предрасположенность — шизофреники.
• Социальный фактор. Отсутствие правил — неясно, что можно; неясно, что нужно. Состояние отчуждения.
• Личные патологии. Невозможность концентрироваться (может, и врожденная). Чрезмерная сосредоточенность на себе (эгоцентризм, личная выгода).

И если сопоставить эти списки с KPI и подобными подходами Мотивации 2.1, то ясно, что они — скорее мешают, чем помогают.

На этом — все. Но тема интересная. От себя хочу добавить, что есть известная книга «Мифы мотивации» Шпренгера, в которой он показывает, как мотивация 2.0 (бонусы и прочие изобретения) приводят в тупик в долгосрочной перспективе даже для продавцов.

Игрофицированный менеджмент (Коробцев Максим, GameTrek)

Максима я слышал на AgileDays, где тоже делал доклад про Gamification. По-русски это называли как «геймификация», однако слово имеет всякие неправильные оттенки, поэтому теперь Максим предпочитает полную русификацию термина.

Начал он с того, что понимание многими игрофикации как раздачи ленточек, вымпелов и других наград — есть, в целом, профанация идеи. Для нее даже специальный термин есть — бейджификация. А профанация это потому, что быстро сваливается в формальность, нет азарта и состояния потока.

Игрофикация — игровая значимость реальных рабочих активностей. И она помогает работе за счет увлечения людей, а еще - за счет того, что доносит в игровой форме до людей правильные приоритеты. Потому что нет проблемы нехватки времени, есть только проблема неверной расстановки приоритетов.

Максим привел три конкретных игры, которые были разработаны и применяются, или планируются к применению для решения конкретных производственных задач.

Первая — track2win. Метафора автомобильной гонки, 12 этапов по месяцам. Ты едешь на машине, плюс собираешь награды. При этом машинки двигаются основной работой, это можно завязывать на багтрекер или другие рабочие показатели. А вот награды связаны с дополнительными активностями, поощряемыми компаниями, например, с выступлениями на конференциях и публикациями. Дальше вопрос тонкой настройки и балансировки. Включая нескольких измерений лидерства. Игра реально используется, по словам докладчика, отрицательных эффектов — не замечено. Есть люди и ситуации, когда игра не действует, но при этом производительность соответствует тому, что было без игры, а не ниже. Пока игра — чистый PvP, то есть конкуренция, они думают, как добавить другие элементы, чтобы была командная работа. А еще — готовят версию с ролями, чтобы разработчики могли соревноваться с тестировщиками, например.

Вторая игра «Коробки», ее запускают для Одноклассников. Цель — устранить технический долг, обеспечить исправление мелких ошибок, за которые берутся неохотно. Идея — каждый месяц вываливается «ящик Пандоры» — коробка ошибок для устранения за заданное время «разбора коробки». Ошибки — персонифицированные, ты помогаешь конкретному пользователю с его проблемой. А еще — нарабатываешь скилы. При этом техника прохождения может быть различной, можно соревноваться в количестве — тогда люди будут брать то, что хорошо умеют, а можно — через «чек-пойнты», разнородные ошибки, если хотим прокачивать кроссфункциональность.

Еще есть игра «NASA против космической угрозы». Когда всякая проблема визуализируется как комета, приближающаяся к Земле, а дальше рабочая группа должна образоваться и с ней справляться, и это — видно.

Как видно, большинство этих техник — они нацелены на решение рутинных или вспомогательных задач, наряду с основной интересной работой.

И принципиально: игра — не обязательно. Но люди — вовлекаются по классической кривой вовлечения.

Right Team: Баланс и Резонанс взаимодействия (Майк Рыжиков)

Майк рассказывал о коммуникациях в командах, построении эффективного командного взаимодействия.

В целом в фундаменте командного взаимодействия лежат три вещи:

• Лидерство;
• Единая Система ценностей;
• Единый профессиональный контекст.

Однако, в докладе о них подробно не говорили. Просто о них надо помнить, говоря о команде. А предметом выступление было выстраивание взаимодействия.

Проблема: результаты взаимодействия часто носят непредсказуемый характер (позитивный или негативный).

В профессиональной команде взаимодействие выдает стабильно-позитивный результат.

Виды взаимодействия.

• Balance 1+1=2. Сильные стороны дополняют друг друга. Надо знать сильные и слабые стороны свои и других. Но! часто есть недооценка или переоценка сторон и с этим надо работать. Например, тренер, оценивающий. Зона применения — исполнение в рамках понятной концепции.
• Resonance 1+1 > 2. Резонирующее — совпадение частот. Гармонизация целей, гармонизация контекста, очередность (у солистов резонанса не будет). Зона применения — генерация идей, надо раскачивать друг друга.
• Anticooperation 1+1 < 2. Его, понятно, надо устранять.

Организованное взаимодействие:

• Создание точек взаимодействия;
• Самоанализ и взаимоанализ;
• Тренер и Тренировочный процесс;
• Фасилитация и Ритуалы;
• Ретроспективы для взаимодействия;
• Работа в парах, Коллективное принятие решений.

В целом, мысли понятные и важные, но по кейсам уровень — не слишком высокий. Потому что у них стабильная многолетняя сложившаяся команда с двумя лидерами — организационным и техническим. Это самая простая конструкция. Хотя, нельзя сказать, что раз она простая — ее просто построить. Далеко не всем это удается, и удачный опыт — ценный. А сложившаяся она — сейчас, они выходят на Performing. На этапе Storming было непросто. А на OpenSpace Майк делился опытом решения проблем.

Методы: SEMAT, А3 и теория ограничений

OMG SEMAT — единая теория программной инженерии (Юрий Куприянов)

Это доклад о новом продукте SEMAT (Software Engineering Method and Theory) — Essence of Software Engineering: Kernel and Language. Я о нем знаю из разных источников, поэтому указанное в описании доклада, услышанное на докладе и узнанное ранее будет перемежаться. А еще — после доклада было много обсуждений, и часть мыслей оттуда.

Основная мысль авторов — проанализировать имеющееся описание разнообразных процессов и методов разработки софта на полном жизненном цикле с тем, чтобы создать язык для их формального описания, и — описать на этом языке имеющиеся методы и практики. И как идеальный результат — вы получаете возможность их сравнить, это во-первых, а во-вторых, — конструировать на их основе собственные процессы и методы. При этом за счет формального описания вы сможете достаточно быстро описывать новым сотрудникам и другими интересантам, чем ваши процессы отличаются от стандартных, а при проведении изменений — чем целевое состояние будет отличаться от того, что есть сейчас. И, наконец, при конструировании можно будет использовать имеющиеся практики из библиотеки, то есть пользоваться опытом индустрии, а не конструировать с нуля.

Пока все подобные описания выполнялись просто текстом, наличие формального языка упрощает ситуацию. Тем более, что, учитывая уроки UML, в язык сразу заложена графическая нотация для эффективного представления. А учитывая развитие Agile-методологий, которые достигли успеха во многом благодаря простоте представления, отличавшей их от тяжелых описаний традиционных методологий, авторы предприняли специальные усилия для упрощения методологии, пусть пожертвовав выразительными средствами и сложностями моделей.

Как идея все это звучит хорошо. Но вызывает опасения, что опять получится нечто громоздкое и слабоприменимое. Глава рабочей группы, которая все это создала, — Ивар Якобсон — один из создателей UML и RUP. И с этим тоже связаны опасения. UML в простых проявлениях — используется много, а вот как полноценный язык — не очень. А на смену RUP как раз и пришел Agile. Но, глядя на результат сейчас, можно сказать — он вдохновляет на использование. Он очень свежий, появился только в этом году, поэтому о полноценном использовании пока говорить рано. Но его пробуют применить в своих проектах. А еще — в обучении, и там он оказался весьма эффективен, потому что позволяет связать все аспекты деятельности в единое целое и дает пути, по которым можно пробовать идти без практического опыта ведения проектов, наполняя содержанием своего модельного или реального проекта.

В докладе был краткий обзор Essence и источников, а практический опыт как раз больше касался знакомства, собственных попыток применения и обучения.

Обзор я совсем кратко повторю. Для начала — терминология. Она во многом оригинальная, и это авторами сделано сознательно. Оригинальная она там, где использование существующих терминов вызывало бы нежелательные коннотации, связанные с применением термина в рамках существующих методологий и процессов и привела бы к потере существенных оттенков смысла. Там, где этого нет, — брали существующий термин, поэтому, например, Customer и Stakeholder — остались. Зато появились Alpha и Endeavor.

Все описание мира разделено на три больших части:

• Предметы - это альфы и их экземпляры, рабочие продукты;
• Деятельность, Activity Space;
• B Competence.

Альфа, для которой придумана расшифровка Abstract Level of Progress Health Attribute — это очень абстрактное понятие. Это нечто, что имеет состояния, по изменению которого мы можем судить о продвижении (Progress) или здоровье (Health) нашей деятельности. И это — идеальный предмет, тип, у которого в реальности возникают экземпляры (Instance) — это рабочие продукты (Work Product). Альфы имеют последовательность состояний, с состоянием связан набор признаков (Check List), которые должны быть зафиксированы для того, чтобы альфа его получила. И связана разнообразными ассоциациями с другими альфами. Деятельность — совершается над экземпляром альфы — рабочим продуктом — или несколькими, и что-то в них изменяет, в результате они могут изменить свои состояния. А компетенции — это способность определенные действия производить. Это если совсем кратко на абстрактном уровне.

На конкретном уровне программной инженерии все поле альф делится на три области.

• Customer — это окружающий мир, заказчики и интересанты.
• Solution — это решение, предмет-результат деятельности, программная система.
• Endeavor — это сама деятельность. В этом месте ранее употребляли слово «Проект», однако Essence описывает деятельность на полном жизненном цикле, а на этапе эксплуатации проекты занимают весьма ограниченное место. Говорят, в рабочей группе SEMAT есть представитель, занимающийся эксплуатацией, и она тщательно вымарывает слово «проект»по площади.

И Essence говорит, что для описания создания софта вам потребуется в этих областях минимально 7 (семь) альф:

• Возможности (Oportunity) и Стейкхолдеры в окружающем мире;
• Требования и Програмная система (Software System) в области решения;
• Работы (Work), Технологии работы (Way-of-Work) и Команды в Endeavor.

Больше — можно. И можно описывать подтипы. Но вот меньше — нельзя.

Дальше для всех основных альф описаны состояния — на полном жизненном цикле. Например, для стекйкхолдеров это Выявлены - Представлены - Вовлечены - В согласии - Удовлетворены развертыванием - Удовлетворены работой системы. Обратите внимание на два последних: это тоже состояния стейкхолдеров. И, естественно, помимо прямого пути возможен откат по графу. Состояние фиксируется для каждого отдельного стейкхолдера или для каких-то групп персонификаций, для всех вместе — как вы построили свое описание.

И это образует Kernel — ядро программной инженерии. Включая карточки чек-листов для состояний. А дальше есть библиотека — описания имеющихся практик и методов. На языке и в понятиях ядра описаны распространенные методы Scrum, User Story и Multi-Phase Waterfall, показано, как выстраиваются комбинации, описаны расширения базовых альф для бизнес-анализа, разработки и управления задачами, и так далее. Например, в расширении для бизнес-анализа наряду с Возможностями и Требованиями появляются Нужды (Need), которые становятся механизмом для движения Возможностей по состояниям. Авторы утверждают, что все известные методы создания и сопровождения программных систем являются комбинацией из менее чем 250 практик. Число большое, но обозримое. И все их можно описать в предложенном формализме и, более того, они это сделают. В обсуждении доклада неоднократно всплывали методы ITIL, их формализации пока вроде не видели (что не означает, что их нет).

Кроме текста стандарта, который достаточно сух, есть книга Ивара — Essence, которая более нацелена на практическое применение. Там есть практические кейсы, причем в вариантах, пригодных как организации обучения с передачей сути, так и для постановки формального процесса, понимаемого через деятельность. При масштабировании надо и то и другое, обучение через деятельность — гораздо более быстрое, и понимание сути не является необходимым для всех.

На сайте Ивара http://www.ivarjacobson.com/ доступно описания практик, а также готовые карточки чек-листов. В русском пространстве метод активно осваивает Анатолий Левенчук, публикуя посты в своем блоге, одновременно адаптируя и расширяя метод на системную инженерию. Он полагает, что это — определенный прорыв и именно в силу простоты изложения и формализма, не взирая на сопутствующие этому ограничения. У него есть перевод терминологии и сделан перевод карточек. Параллельно и взаимодействуя работает русское отделение SEMAT, которое тоже ведет перевод стандарта и книги Ивара. Словарь доступен здесь, работа идет в тесном контакте с основным SEMAT.

С готовыми артефактами библиотеки и связано возможное применение стандарта сразу. Вы можете просто распечатать карточки и читать их, сравнивая с ними свой процесс. Как сказал Юрий, сначала есть ощущение, что читаешь очевидные и известные вещи, пока не добираешься до пунктов, о которых сам почему-то не задумывался :) И часть этих пунктов можно сразу применять, и в работе и даже включая в договора. Юра так уже делал. Конечно, такой договор сложнее заключить, но по нему легче работать. Более того, ему уже реально приходилось апеллировать к этому в разборках. При чем отношения с заказчиком сохранились, и даже увеличилось уважение со стороны заказчика, а еще тот начал договора читать :)

А еще карточки можно применять в обучении, и это Юра тоже делал на Физтехе. Потому что в разных курсах студентам дают различные составляющие процесса создания ПО, а комплексная картинка не возникает. Карточки позволяют ее сложить, причем сразу в достаточно конкретном виде, пригодном для того, чтобы двигать свой проект.

За дальнейшими ссылками и содержанием отсылаю к слайдам Юры, которые он уже выложил. А в обсуждении, откуда начать знакомиться, возникла идея, что тут неплохо сработает обучение бросанием в воду. Берешь один из последних постов Левенчука, например, этот и копаешь по ссылкам в прошлое и на стандарты, пока не станет понятным. А на SECR можно будет не только услышать Ивара, но и пообщаться с ним в дискуссионном уголке.

Опыт применения A3 в компании Skype (Алексей Ильичев)

A3-анализ — это подход к решению стратегических проблем, применявшийся в «Тойоте». Суть его в том, что под одну проблему заводится лист формата А3, на котором коротко изложена суть проблемы, анализ и контр-меры. Алексей рассказывал о том, как в компании Skype они пробуют применять этот метод на трех практических кейсах.

Кейсы: проблемы с дизайнерами, из-за запаздывания работы которых возникали сложности с релизами, проблема с разрешением на использование Opensource-библиотек и организация работы с QuickBuild.

Сразу скажу, что во всех случаях проблемы решались просто от их осознания и обсуждения. В случае с Opensource вообще оказалось, что ответственные лица готовят документ, и через полгода будет счастье. Только ситуация была такова, что полгода ждать было нельзя и нужно было временное решение, и проведенный анализ как раз обосновывал остроту ситуации. Подробно описывать кейсы я не буду, интересующиеся могут посмотреть запись, когда она появится.

Практически формат использовался как решение проблемы снизу, в любом месте, где она возникает. Роль формата А3 в том, что при этом любой сотрудник, заинтересованный в проблеме, но не имеющий навыка решения, получает форму, следуя которой он может продвигаться, обсуждая проблему на всех уровнях и получая доказательную базу для обсуждения с руководством. Я знаю, что этого часто не хватает: тот, у кого болит, — не знает, как подступиться к проблеме, а тот, кто это умеет, — занят реально более важными вещами, да и донести важность проблемы у него не получается.

Шаблон А3 есть в Инете, они брали уже как-то адаптированный из книги Тома Поппендик и Генриха Книберга. А3 Problem Solving Template. Важно, что заполнять его надо так, чтобы понял генеральный директор (условно), а не техническим сленгом, — тогда с высокой вероятностью поймут все, с кем будете обсуждать. Начинали они с реально бумажного шаблона, и пока ты в пределах офиса, бумага с карандашом для обсуждений — удобнее. Но у них много офисов разработки, и с выходом за пределы офиса они переходили в Wiki, и там же рисовали графы Root Cost Analysis, расшаривая рабочий стол при обсуждении.

Теория Ограничений для ИТ: информационные ограничения и управление временем (Андрей Степенко)

Это был весьма странный и неожиданный доклад. Начался с того, что кроме физических ограничений, которые надо учитывать, используя теорию ограничений, существуют информационные. И в результате проекты с большим бюджетом не могут быть сделаны, потому что процедура принятия решений оказывается долгой и становится узким горлом. Правда, с мест качали, что, может это тоже физическое ограничение, связанное с отсутствием способных людей. Но, все-таки, по разным причинам так может быть.

В качестве позитивных примеров, как эти ограничения можно обойти, приводились Opensource проекты, в которых система принятия решений распределена. Правда, без подробностей внутреннего устройства. Но с общим тезисом, что так происходит, потому что там люди увлечены делом и сознание находится в согласии с деятельностью. А еще ум расслаблен и не зашорен. И с этого места Андрей перешел к тому, что есть такая техника — цигун — которая позволяет расслабляться и приводить сознание в спокойное и эффективное состояние. Нам немного про цигун рассказали, а потом были практические занятия. Прикольно. Но, по-моему, не по делу. Может, потому, что я и так хорошо прихожу в эффективное рабочее состояние...

А кроме цигуна Андрей еще сказал, что есть такой GTD Аллена. Одним из эффектов которого является достижение бесстрессового состояния, что тоже повышает результативность мышления.

Mind Map доклада

Разработка документации

А еще на конференции было два практических кейса, касающихся документации.

Гибкая разработка пользовательской документации (Сергей Рогачев)

Проблема документирования — известно-плохо-решаемая. Ребята применили известные подходы — включение в итерации, включение в DoD для Userstory и трассировка фичи-документации. И у них заработало.

Что интересно в докладе — достаточно подробные документы, как у них организовано. Например, в описании DoD указано, что именно надо не забыть поправить (типа, часто Title забывают поправить), а отдельно — каковы самые частые нарушения. Трассировку делали через автосборку на TFS из Word. И приведенные примеры покрывают не только документирование, поскольку оно тесно связано с остальным процессом. А заглянуть в организацию процесса у других — всегда интересно, можно почерпнуть новые идеи.

И они поделились отдельным инструментом, который они используют. TeamSolution TeamSpec — плагин к VS. Они сделали отдельный WorkItem Document Item и именно там пишут документацию. Плагин это собирается в Word, а еще позволяет там редактировать с сохранением изменений в исходный Document Item.

Разрушители мифов: Agile и аутсорс» (Инга Юрьева)

В докладе рассказывалось о процессах документирования и локализации в Лаборатории Касперского. Проблема возникла после того, как они вышли на международный рынок. И основная версия выходит на 6-8 языках, а через 2-3 недели — еще 30-50 дополнительных языков. Работы по локализации были переданы из отдела в отдел документирования. При этом разработка естественным образом часто идет до последних дней, но документацию и локализацию надо успеть сделать. Еще одна особенность — в работе участвует достаточно много внешних сотрудников, поскольку для хорошего перевода нужно редактирование носителями языка.

Процесс был первоначально построен под водопадную разработку. А потом, с внедрением Agile в разработке — перестроен с его учетом. Правда, их пугали, что Agile и аутсорс несовместим и качество упадет ниже допустимого. Но реально Agile повлиял не слишком — из-за того, что разработка велась до последних дней, многое в процессе уже было. Но в целом было рассказано достаточно много подробностей и особенностей, касающихся построения процесса. А основа успеха — тщательный подбор персонала по Soft Skill — культуре, коммуникациям, мотивации... И внешних сотрудников они держат на постоянной основе, перейдя от аутсорса к аутстафу.