Попытался изложить ключевые аспекты организации рекрутинга в виде ментокарты.

По ссылке карта в pdf и mmap.

Техническое задание и план-график работ согласованы, предоплата поступила, проект идёт. Заказчик получает первую версию продукта и, вот сюрприз, его ожидания изменяются.

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

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

Для фиксации изменений требуются два артефакта — реестр изменений (особенно критичен для больших проектов) и карточка изменения.

Карточка изменения

• Название проекта
• Дата актуализации
• Текущий статус
• Описание изменения
• Причина изменения
• Влияние изменения
• Резолюция заказчика
• Резолюция исполнителя

Шаблон

Реестр изменений

• Название проекта
• Дата актуализации
• №
• Описание изменения
• Инициатор изменения
• Статус изменения
• Дата получения информации

Шаблон

— Но, сэр, я это и хочу сказать. Предположим, вы вообще не вооружены. Или этим вашим прутиком, например. А противник весь увешан опасным оружием. С этим ничего не поделаешь, он заставит вас сапоги ему вылизывать.

Ответил Зим почти ласково.
— Ты все неправильно понимаешь, сынок. Нет такой штуки, как «опасное оружие».
— Э-э… сэр?
— Не существует опасного оружия, есть опасные люди. Мы пытаемся научить вас быть опасными — для противника. Даже без ножа. Смертоносными, пока у вас есть хотя бы одна рука или нога, пока вы еще живы. Если не понимаете, о чем я говорю, идите и прочитайте «Горация на мосту»* — книга имеется в библиотеке лагеря. Но сначала рассмотрим твой случай. Я — это ты, и все, что у меня есть,— это нож. Мишень позади меня, та, по которой ты промахнулся, номер три — это часовой, вооруженный всем, кроме ядерной бомбы. Тебе надо его снять… бесшумно, быстро и не дав ему возможности поднять тревогу.

Зим чуть повернулся — чпок! — и нож, которого у него даже в руках не было, дрожит в центре мишени.
— Ясно? Лучше иметь при себе два ножа, но сделать часового ты должен даже голыми руками.

Р. Э. Хайнлайн, «Звёздный десант».

 
 
 
«Оди́н» — самое плохое слово в бизнесе. Если вы зависите от одного файла, компьютера, банковского счёта, сотрудника, поставщика, у вас проблемы.

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

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

Пусть критически важную функцию А в течение первой недели делает сотрудник Б, а на следующей неделе его меняет сотрудник В. Потом обратно. Неудобно? Это лучше ситуации, когда единственный и незаменимый сотрудник А внезапно увольняется.
 
 
Итак, избавляйтесь от слова «один» в бизнесе и жизни.

По долгу службы я сейчас много работаю с фрилансерами. Уже потихоньку начало формироваться мнение, каким должен быть фрилансер, с которым будет хотеться вести дела снова и снова.

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

 
1. Обговорить и сообщить менеджеру, сколько времени можешь уделять проекту. Чётко зафиксировать, в какое время можно звонить, в какое — только писать, а в какое будешь недоступен.

2. Отвечать на сообщения сразу, не тупить. Если не можешь ответить сразу — пиши, когда именно ответишь.

3. Заранее предупреждать, что работа займёт больше времени, чем предполагалось, чтобы менеджер успел корректно сдвинуть сроки.

4. В первую очередь думать о качестве продукта и только во вторую — о деньгах. Менеджер не заинтересован кидать хороших фрилансеров, намного рациональней выстроить отношения с фиксированным пулом людей и периодически снабжать их работой.

5. Если менеджер просит работать с задачами в редмайне, джире или любой системе таск-трекинга, своевременно ставить задачам актуальное состояние и списывать на них потраченное время.

Обратил внимание, что ранее, приходя в новую компанию, около недели тратил на то, чтобы минимально обставить рабочее место, получить доступы к нужным сервисам и хоть как-то разобраться, кто за что отвечает, как кого зовут и к кому по какому поводу обращаться.

В одной компании дело дошло до маразма — по должности мне было положено принимать дизайн, но монитор выдали ЭЛТ-шный (нет, не профессиональный ЭЛТ-шный, а пятнадцатидюймовый гробик 1024 на 768, на котором невозможно нормально откалибровать цвета). Пришлось потратить массу времени на убеждение сисадмина, затем своего начальника. Кстати, это не помогло, монитор заменили только после вмешательства генерального.

Суть адаптации нового сотрудника — сделать два чек-листа.

В первом написать, что нужно сделать до прихода сотрудника (вытереть стол от пыли, поставить оборудование в соответствии с должностью, подготовить бумаги для оформления, сделать пропуск и так далее)

Во втором написать, что нужно сделать после прихода сотрудника (рассказать, во сколько приходить, когда обед, когда уходить, можно ли работать из дома, выдать зарплатную карту, показать, где наливать кофе и куда выбрасывать мусор и так далее).

Затем нужно лишь применять эти два чек-листа к каждому новому сотруднику.

Ещё можно сделать страницу «Информация для нового сотрудника» в корпоративной вики, если такая у вас имеется.

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

По слухам, сюжет будет построен вокруг конфликтов бостонских группировок — «Института», Братства Стали, Железнодорожников из Убежища 79 и разных мелких банд.

Главным героем будет мужчина без возможности выбрать пол — такова особенность сюжета. Предполагается, что протагонист с женой и ребёнком застанут ядерную атаку, скроются в убежище 111, где их закриогенят на столетия. Интересный момент. Главгерой по прозвищу «Офицер» будет полностью озвучен, впервые не только за всю серию Fallout, но и вообще, всех игр Bethesda.

Дата выхода игры пока неизвестна, но велика вероятность, что релиз состоится в этом году на PC, PS4 и Xbox One, также возможен выход версий для старых приставок PS3 и Xbox 360.

Не может не радовать, что основной платформой будет всё-таки PC, можно ожидать нормальный инвентарь и интерфейс, не заточенный под геймпад.

Второй день гоняю в Pillars of Eternity. Это такой отход к традициям классических RPG — изометрический вид, много-много диалогов, куча рас и классов, немеряно параметров и навыков, причём каждое вложенное очко влияет на геймплей.

Самым интересным показалось то, что в неё нельзя играть нахрапом. Очень давно забытое ощущение, когда вместо бодрого спидрана и выноса всех подряд ты крадёшься по локациям, по возможности избегая боёв, а каждый бой превращается в тактическую головоломку (главное — не ставить самый низкий уровень сложности, тогда удовольствия не будет).

Понимаете? Взял квест на возвращение кузнецу украденного товара, пошёл с напарником-магом в локацию, нашёл пятерых бандитов у костра. Ну чо, ща вынесу их и всё. Ога. Вынес с шестнадцатой попытки, после того, как вернулся в селение и добавил к магу наёмника-рейнджера с ручным ведмедем.

Забытый стиль боя «дверной ниндзя». Первый и второй танк по бокам от двери, справа медведь, в метре от танков варвар, на задней линии жрец и маг. Хантер идёт вперёд и из невидимости агрит противника калечащим выстрелом. Тактическая пауза, жрец произносит поддерживающее заклинание, первый танк готовит повышение меткости, второй — какую-то паладинскую приколюху, варвар входит в боевое безумие. Хантер драпает назад, пробегает через дверь, становится рядом с магом, варвар делает шаг вперёд и смыкает строй у дверей. Жрец кидает шестисекундное молчание на мага противника, наш маг дезориентирует воина противника, добежавший хантер оставшимися калечащими выстрелами мочит вражеских лучников…

Маги могут прочитать ограниченное количество заклинаний. Лимит закончился — нужен привал. Для привала нужны припасы. С собой единовременно можно тащить не более четырёх комплектов припасов для привала.

Двумя постами ниже я жаловался, что в боевике COD нет возможности выбора. В этой игре большая часть квестов содержит дилемму с отсутствием единственного правильного ответа. Исполнить данное в начале квеста обещание убить лорда Редрика и отдать регион под контроль его младшему брату? Но в подвале замка Редрика сидит тётка-анимансер, занимающаяся очень важным исследованием, младший брат Редрика такое не одобряет. Может, нарушить обещание и наоборот, за хорошую сумму помочь Редрику избавиться от братишки? Можно поступить как угодно.

А ещё, можно делать противоречивых персонажей. Магов с двуручниками, умных варваров и подлых паладинов.

В общем, у этой игры не просто так девять баллов от Игромании.

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

№ 1. Проводить преобразования системно

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

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

Системность преобразований нельзя путать с «пилотированием». В ряде случаев имеет смысл обкатать нововведение на фокусной группе и оценить его эффективность.

№ 2. Начинать с «низовых» потребностей

Пётр Акрадьевич начал систему реформ (имея системный план, конечно) не с провозглашения либеральных свобод, а с самого низа — с обеспечения нормальной жизнедеятельности крестьян и рядовых граждан. Как не может нормально функционировать государство, в котором простое население живёт за чертой, так и не будет эффективной организация, в которой невовремя выплачивается зарплата, возникают перебои с электричеством или теплоснабжением в офисе.

Например, если мы говорим о компании-разработчике ПО, начинать надо с базовых процессов. Система постановки задач, багтрекер, система связи, сборка продукта в одно действие, учёт плановых и фактических затрат, техническая документация, рецензирование кода. Основные вещи. Только тогда, когда они заработают без сбоев, можно думать о более «высокоуровневых» преобразованиях.

№ 3. Соблюдать стратегические интересы

Придерживаться стратегического плана развития, не упускать из виду основную цель, намного важнее, чем решить сиюминутные задачи.

Например, внедрение очереди запросов — не слишком популярное решение. Заказчики обязательно будут ругаться и давить, потому что надонадонадо срочносрочносрочносрочно. Однако если не организовать очередь, бардак не прекратится никогда.

Что сделать? Небольшую доработку, которая принесёт условные 60 000 руб. через месяц или отрефакторить алгоритм работы с кэшем, что ускорит работу продукта на 15-20 %, но не принесёт прямой прибыли? Если наша цель — качественный продукт, то безусловно, второе. Но лучше бы планировать работы так, чтобы подобных альтернатив не возникало.

№ 4. Проводить селекцию кадров

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

Нанимаем медленно, увольняем быстро; всегда даём второй шанс, никогда не даём третий; ставим на ключевые посты «умных лентяев».

№ 5. Добиваться исполнения регламентов

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

Внедрение любого регламента требует времени. Опыт показывает, что обязательно есть несколько человек, хронически неспособных этот регламент соблюдать. Нужно обязательно заморочиться и понять, что им мешает (может быть, регламент нерационален? Может быть, мы его плохо продумали, надо внести правки?) и долбить, долбить, долбить, пока регламент не будет соблюдать весь коллектив.

Разработка ПО отличается от других видов производства возможностью дать команде высокую степень свободы. На ранних стадиях подход «атмосферы стартапа» себя оправдывает — замотивированная команда трудится над созданием первой версии продукта, первоочередная задача — побыстрее получить демо-версию продукта.

Проблемы вылезают значительно позже, когда ПО «выстреливает» и становится успешным. Компанию приходится масштабировать, привлекать новых сотрудников. Очень быстро начинаются проблемы вида:

— А почему ты не сделал %действие%?
— Не знал, что его нужно делать. / Не знал, что это — моя сфера ответственности.
 
 
Импульсивный руководитель может сказать: «Не хотите по-хорошему? Нате тогда вам регламент!» и зарегламентировать всё подряд. Плохой подход. Опыт показывает, что разработка ПО — сфера «постоянных изменений». Регламент необходим, но он не должен быть похож на проверку самолёта на готовность к вылету.

Зачем нужен регламент?

 
Плюсы:
 
 Стандартные действия сотрудников в повторяющихся ситуациях.
 Стандартные сроки для исполнения повторяющихся процедур.
 Руководителю больше не нужно объяснять новым сотрудникам простые процедуры.
 Сотрудники не конфликтуют между собой — каждый точно знает свою сферу ответственности.
 В ходе разработки регламента можно избавиться от ненужных активностей.
 Процесс контроля упрощается, деятельность компании становится более структурированной.
 
 
Минусы:
 
 В условиях «постоянных изменений» нужно не лениться держать регламент актуальным.
 Для «творческих» сотрудников составить регламент можно далеко не всегда.
 
 
Регламент необходим, когда:
 
 В компании больше одного отдела.
 Регулярно возникают повторяющиеся проблемные ситуации.

Типичные ошибки

 
Самых частых ошибок три:

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

Алгоритм подготовки регламента.

Компоненты регламента

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

Пример регламента

 
Название и назначение процесса:
Первичная оценка ЗЗЛ. Нужна для того, чтобы максимально быстро выделить бизнес-проблему заказчика, сформировать вариант реализации, дать примерную оценку доработки в часах. Получив эту информацию, заказчик может составить представление о том, готов ли заказывать написание требований и реализацию доработки.
 
Владелец: Руководитель отдела анализа и проектирования.
Инициатор: Любой сотрудник отдела внедрения, отдела продаж, отдела поддержки.
Участники: Сотрудники отдела анализа и проектирования.
Контролёр: Глава департамента разработки.
 
Правила запуска процесса:
Инициатор вносит запрос в бэклог, запрос проходит приоритезацию (См. регламент работы с бэклогом) и получает место в общей очереди.
Владелец, получив от сотрудника отдела анализа и проектирования (далее «аналитик») информацию о том, что у него менее двух запросов в активной фазе (См. общие правила работы сотрудников отдела анализа и проектирования), на своё усмотрение выбирает запрос из первой пятёрки очереди и переводит его на этого аналитика.
 
Входной артефакт:
Правильным образом заполненный запрос в общем бэклоге (См. регламент работы с бэклогом) в состоянии «Первичная оценка».
 
Основной сценарий:
Аналитик уточняет у инициатора актуальность запроса.
Аналитик организует телекон с представителем заказчика для уточнения бизнес-проблемы.
Аналитик запрашивает у менеджера продукта, кто из разработчиков может проконсультировать по оценке.
Аналитик объясняет разработчику суть бизнес-проблемы, разработчик предлагает решение и оценку.
Аналитик применяет к оценке поправочные коэффициенты (См. формулы первичной оценки).
Аналитик вносит в запрос оценку, уточнённую бизнес-проблему и выработанный вариант реализации.
Аналитик формирует документ «Первичная оценка» (См. пример документа).
Аналитик отправляет документ «Первичная оценка» инициатору.
Аналитик переводит запрос в состояние «Согласование первичной оценки.
 
Выходной артефакт:
Запрос бэклоге имеет состояние «Согласование первичной оценки», заполнены поля бизнес-проблемы, варианта реализации и оценки в часах.
Документ «Первичная оценка», отправленный инициатору.
 
Правила завершения процесса:
Положительный сценарий: Инициатор подтверждает готовность заказчика к этапу точной оценки, аналитик переводит запрос в состояние «Очередь для точной оценки», инициализируется процесс точной оценки (См. регламент точной оценки)
Отрицательный сценарий: Инициатор сообщает об отказе заказчика от доработки, аналитик переводит запрос в состояние «Отменено».
 
Диаграмма:

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

Управление изменениями

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

Общие правила изменения регламентов:

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

Резюме

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

P. S. Вот хороший пост о регламентах из телеги: