2013-10-12: Впечатления с AgileKitchen

Короткая ссылка: AgileKitchen-2013-10-11

Ссылки сюда (3) →

Серия осенних конференций началась с 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 они пробуют применять этот метод на трех практических кейсах.

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

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

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

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

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

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

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

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

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

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

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

Проблема документирования - известно-плохо-решаемая. Ребята применили известные подходы - включение в итерации, включение в 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 - культуре, коммуникациям, мотивации... И внешних сотрудников они держат на постоянной основе, перейдя от аутсорса к аутстафу.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— MaksTsepkov • 21:19, 12 октября 2013 • нет комментариев