Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Месяц: Февраль, 2015

Перевод превью комик-бука к сиквелу «Бойцовского клуба»

На сайте «Плейбоя» было опубликовано шестистраничное превью комик-бука к мегаожидаемой книге — сиквелу к культовому «Бойцовскому клубу» Чака Паланика. Взял на себя смелость сделать перевод:

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

Ссылки на случай бана публикации на Calameo:
Перевод превью к комик-буку «Бойцовский клуб-2, скачать по прямой ссылке.
Перевод превью к комик-буку «Бойцовский клуб-2, скачать из Эвернота.

Шпаргалка по Sublime Text 2

sublime text 2 mac

sublime text win

Базовый чеклист для ревью кода

Ревью кода

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

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

Общее
Работает ли код? Выполняет ли он свои прямые обязанности, корректна ли логика, и т. д.
Легок ли код для понимания?
Соответствует ли код вашему стилю написания кода? Обычно это относится к расположению скобок, названиям переменных и функций, длинам строк, отступам, форматированию и комментариям.
Есть ли в ревью избыточный или повторяющийся код?
Является ли код независимым, насколько это возможно?
Можно ли избавиться от глобальных переменных или переместить их?
Есть ли закомментированный код?
У циклов есть установленная длина и корректные условия завершения?
Может ли что-то в коде быть заменено библиотечными функциями?
Может ли быть удалена часть кода, предназначенного для логгирования или отладки?

Безопасность
Все ли входные данные проверяются (на корректный тип, длину, формат, диапазон) и кодируются?
Обрабатываются ли ошибки при использовании сторонних утилит?
Выходные данные проверяются и кодируются (прим. пер.: например, от XSS)?
Обрабатываются ли неверные значения параметров?

Документация
Есть ли комментарии? Раскрывают ли они смысл кода?
Все ли функции прокомментированы?
Есть ли какое-то необычное поведение или описание пограничных случаев?
Использование и функционирование сторонних библиотек документировано?
Все ли структуры данных и единицы измерения описаны?
Есть ли незавершенный код? Если есть, должен ли он быть удален или помечен маркером типа «TODO»?

Тестирование
Является ли код тестируемым? Например, он не должен содержать слишком много зависимостей или скрывать их, тестовые фреймворки должны иметь возможность использовать методы кода, и т. д.
Есть ли тесты и если есть, то достаточны ли они? Например, они покрывают код в нужной мере.
Юнит-тесты на самом деле проверяют, что код предоставляет требуемую функциональность?
Все ли массивы проверяются на «выход за границы»?
Может ли любой тестирующий код заменен с использованием существующего API?

Источник

+2 Гб в Google Drive за две минуты

Нужно всего лишь проверить основные параметры безопасности вашего гуглоаккаунта. Занимает ровно две минуты. На выходе получаете такую картинку:

Основные параметры безопасности гуглоаккаунта
 
 
Есть нюанс. Это действие нужно произвести до 17 февраля. Судя по записи в гуглоблоге, 28 февраля ёмкость гуглодисков всех участников будет увеличена на два гига (об этом уведомят письмом).

Пользователи Google Apps for Work и Google Apps for Education в акции не участвуют.

Конфликты между старыми и новыми сотрудниками.

noob

Управление конфликтами между ветеранами и новичками строится на трёх компонентах: отборе, информировании и наставничестве.
 
 

Предотвращение

Методы предотвращения

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

Собеседование.

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

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

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

Подготовка коллектива.

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

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

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

Первые задачи.

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

Особенно важно дать время на адаптацию новичку, являющемуся наёмным руководителем:

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

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

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

Такая ситуация продолжалась довольно долго, пока генеральный директор, проанализировав ее, понял, что лозунг «Если ты профессионал – тебе все равно с кем работать» неверен.

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

 
 

Активное противодействие

Методы борьбы

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

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

Переубеждение Переубеждаем.

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

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

Вовлечение Вовлекаем.

Берём самых опытных «старичков» и прикрепляем к каждому «новичка» в качестве стажёра. Было: «Понанимали не пойми кого по объявлениям», стало: «У меня есть стажёр. Я крут».

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

Геймификация Геймифицируем.

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

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

Мотивация отдыхом

motivation

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

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

Работники на окладе.

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

Работники с переменной частью:

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

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

Но, это чистые «сдельщики», скажете вы. А как быть с постоянными работниками? А вот так:

Выясните, что важно для ваших менеджеров, и предложите им это взамен. В моей практике был случай: на авиационно-технической базе четыре бригады техников не успевали с ремонтными работами на самолетах. А было самое горячее время: лесные пожары, обработка полей химией и т. д.

Я проанализировал ситуацию и выяснил, что пик работ у большинства сотрудников совпадал с сезоном охоты, рыбалки, сбора грибов и ягод. И тогда предложил создать «дикую бригаду». Собрал добровольцев среди техников и объяснил: стандартный план по ремонту – пять самолетов в месяц, я увеличиваю план на 40 %, то есть ставлю в него семь самолетов, и если он выполняется, то до конца месяца техники на работу могут не выходить и посвятить оставшиеся дни охоте и рыбалке.

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

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

Владимир Яковлев,
Председатель совета директоров и владелец компании «Абсолют», Архангельск

 
 
Такой вот малоизвестный, но ломовой приём. Ради 5-6 тыс. прибавки к премии далеко не каждый готов работать максимально быстро и безошибочно, а вот за возможность сделать как можно быстрее ограниченный объём работ и отправиться домой, можно и постараться.

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

Матрица взаимных ожиданий.

Expect the unexpected

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

Ожидания разработки Ожидания тестирования Ожидания внедрения
Обязательства разработки Олли Мяяття:
Осси Вяанянен:
Лассе Кукконен:
Сами Сало:
Теему Селянне:
Олли Йокинен:
Обязательства тестирования Яркко Иммонен:
Петри Контиола:
Лаури Корпико:
Сами Сало:
Теему Селянне:
Олли Йокинен:
Обязательства внедрения Яркко Иммонен:
Петри Контиола:
Лаури Корпико:
Олли Мяяття:
Осси Вяанянен:
Лассе Кукконен:

 
В примере три отдела — разработка, тестирование, внедрение. В каждом работает по три сотрудника:
Разработка: Яркко Иммонен, Петри Контиола, Лаури Корпико.
Тестирование: Олли Мяяття, Осси Вяанянен, Ласси Кукконен.
Внедрение: Сами Сало, Теему Селянне, Олли Йокинен.
 
Таблица расшаривается на всю компанию. Это важный момент — заполнить её должны не только руководители подразделений, но и сотрудники. Каждый сотрудник пишет, что именно он ожидает от других отделов.
 
 
После заполнения может получиться следующее:

Ожидания разработки Ожидания тестирования Ожидания внедрения
Обязательства разработки Олли Мяяття:
Основной поток должен работать без ошибок на компьютере разработчика.

Осси Вяанянен:
Передаваемый код должен быть покрыт модульными тестами.

Лассе Кукконен:
Передаваемый код должен содержать комментарии.
Сами Сало:
Соблюдение сроков разработки, предоставление пояснительной записки.

Теему Селянне:
Быстрое исправление дефектов, обнаруженных заказчиком.

Олли Йокинен:
Умение проводить доработки, взаимодействуя с внедренцем напрямую.

Обязательства тестирования Яркко Иммонен:
Своевременное предоставление тестовых планов.

Петри Контиола:
Участие в выработке варианта реализации.


Лаури Корпико:
Своевременно давать фидбек по протестированной доработке.
Сами Сало:
Передавать только доработки, не содержащие дефектов.

Теему Селянне:
Не затягивать тестирование.

Олли Йокинен:
Умение быстро выявлять причины дефектов, найденных заказчиком.

Обязательства внедрения Яркко Иммонен:
Предоставление грамотных ТЗ.


Петри Контиола:
Своевременные ответы на вопросы в процессе разработки.

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

Осси Вяанянен:
Внедренецы должны принимать участие в регрессионных тестах.

Лассе Кукконен:
Внедренцы должны обеспечивать обратную связь после передачи протестированной доработки.

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

Отдел Обязательство Показатель План
Разработка Основной поток перед сдачей на тест работает на компьютере разработчика без ошибок. Количество замечаний тестировщика но ошибкам в основном потоке в доработках, сданных на тест. (Фиксируется в задаче на тестирование). Количество замечаний по ошибкам в основном потоке за месяц/Количество доработок за месяц не более 0,3.

Пример:
10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен.
10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
Передаваемый код должен быть покрыт модульными тестами. Процент покрытия процедур модульными тестами. (Фиксируется в задаче на тестирование) Среднее покрытие процедур модульными тестами не ниже 90 % в месяц.
Доработки должны сдаваться в срок. Разница между датой дедлайна и датой передачи доработки заказчику (Фиксируется автоматически по закрытию задачи на сдачу заказчику) Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку.

Пример:
В среднем, 9 дней на доработку по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.

Дефекты, пришедшие от клиента должны закрываться максимально быстро. Среднее время закрытия дефекта. (Фиксируется в дефекте) Среднее время закрытия дефектов с признаком «дефект от клиента» не больше 2 рабочих дней.
Тестирование Своевременно предоставлять тестовые планы. При передаче требований в работу, к задаче на разработку должна быть прикреплена ссылка на тестовый план. Процент покрытия передаваемых доработок тестовыми планами не ниже 95 %
Передавать внедренцам только доработки, не содержащие дефектов в основных и альтернативных потоках. Количество дефектов от клиента на протестированные данным тестировщиком доработки. Отношение количества дефектов от клиента на доработки данного тестировщика к количеству переданных доработок не выше 0,3

Пример:
10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен.
10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
Тестирование должно проводиться максимально оперативно. Среднее отклонение фактических дат от плановых. Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку.

Пример:
В среднем, 9 дней на тестирование по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.

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

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

Подобный подход способен решить массу внутренних проблем и конфликтов.