Особенности профессионального найма

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

К сожалению, не все готовы признать реальное положение вещей. Личный комплекс “власти”, неискренность по характеру, эгоцентричность и другие штуки – приводят к тому, что работодатель начинает рассуждать в контексте “я нанимаю”. Я нанимаю – значит я имею право, а “он” прав не имеет. Жестокая реальность потом больно бьёт по голове, когда приходит осознание что кандидат (да и сотрудник) тоже выбирает вас как долгосрочного партнёра. Иногда это осознание приходит только с уходом ключевых людей, которых конкуренты перекупают как горячие пирожки. Continue reading “Особенности профессионального найма”

О руководителях военного и мирного времени

Этот пост – отклик на провокационную статью о так называемых руководителях мирного и военного времени, опубликованной на слоне.

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

Короче говоря, это очередной взгляд на борьбу сил Добра и Зла, Процесса и Результата, – моя любимая тема, которую я не мог оставить без внимания. Как всегда, где есть два противоборствующих лагеря, скорее всего не правы ни те, ни другие. Давайте разберёмся. Continue reading “О руководителях военного и мирного времени”

Три стратегии принудительной реорганизации проектов и команд

Мотивами поста послужили недавние события, произошедшие с проектом Lenta.ru. Если кто не в курсе, то перечислю: уволен главный редактор, генеральный директор, а так же уволились 39 сотрудников “Ленты”. Ссылки на первоисточники вы легко найдёте в гугле.

Но если оставить за рамками поста политику и бизнес, то удивление вызывает сама реакция как сотрудников “Ленты”, так и читателей – простых и непростых обывателей нашей с вами страны. Словно они наблюдают подобную ситуацию в первый раз, не понимают что происходит, выдвигают множество версий и высказывают множество эмоций.

Автор этих строк, сменив более 6 мест работы в крупных компаниях, неоднократно сталкивался с корпоративными политическими играми, и поэтому позволит себе провести трезвый анализ ситуаций подобных этой. Continue reading “Три стратегии принудительной реорганизации проектов и команд”

Когда записывать, и когда не записывать задачи в таск-менеджер

Тут Мегаплан постепенно приобретает человеческое лицо, и начинает понимать что нельзя “с наскока” внедрить процесс постановки задач, как лампочку Ильича, в каждую избу на деревне. Выскажу и я своё скромное мнение.

Существует две крайности относительно постановки задач: одна из них – полное отсутствие таск-менеджера вообще, передача задач устно, по аське, по е-майлу, на стикерах к монитору. Вторая – запись всего-всего-всего в таск-менеджер, и обсуждение всех подробностей и шагов решения задачи там же в комментариях, даже между людьми сидящими за соседними столами.

В реальности большинство компаний болтаются где-то между, что-то записывая в трекер, а что-то передавая исключительно на словах. Давайте разберёмся, что же там происходит и почему. Для начала – лирическое отступление и правда жизни:

Даже тщательное ведение таск-менеджера не приближает вас к успеху проекта.

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

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

Вернёмся к теме:

Записывать в таск-менеджер (трекер) нужно:

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

Когда задача – это на самом деле баг. Баг, как сущность, – это формализованно описанная проблема. Есть даже мантра тестировщиков, помощающая составить хорошее описание: что я делал, что я получил, что я ожидал получить. Говоря умными словами – шаги по воспроизведению, полученный результат, ожидаемый [по спецификации] результат. Однозначно записывать, иначе потеряется.

Когда задача ясна от начала до конца. Бывают такие задачи, над которыми не нужно думать, а нужно просто сделать. Добавить такие-то виртуальные хосты под такое-то число сервисов, вот список. От человека требуется взять и накатать рецепты в chef. Не нужно долго думать, достаточно сработать по известному алгоритму, и требуемый результат чётко понятен.

Когда задача содержит много формализованных значений. Например, увеличить максимальную длину логина с 8 до 16 символов, и допускать логины начинающиеся только с маленькой буквы из диапазона [a-z].

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

Записывать в таск-менеджер (трекер) НЕ нужно:

Когда задачу лучше сделать прямо сейчас. Как в GTD есть правило – если входящее письмо требует меньше двух минут на решение, то нужно решать сразу, не перекладывая в todo или later. Так и в разработке – если проще обсудить и тут же решить, то надо обсудить и тут же решить. Вспоминаем начало этого поста, если забыли.

Важно, чтобы это реально была задача класса “быстро решить”, а не бравада вашего разработчика в стиле “плавали-знаем”, которая выльется в полдня работы.

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

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

Автор этих строк пользуется простым методом, и вам рекомендует: берите свой айфон и фоткайте все эти листики. Или маркерные доски, если там нарисовано. Это и будет документацией, если она вдруг понадобится кому-то из коллег.

Когда задача очевидна. Говоря другими словами, когда мимо неё не пройти, не споткнувшись. Очевидно, что в проекте должен быть процесс деплоя (скрипты, выполняющие выгрузку новой версии в продакшен). Очевидно, что у проекта должны быть группы dev-, stage-, prod-серверов. Очевидно, что когда у интернет-магазина есть корзина, то должен быть и способ фиксации заказов.

Замечание: речь про собственные (внутренние) проекты. Это не подходит, если вы работаете по fix-price и фиксированному ТЗ с внешним заказчиком.

Когда конечный результат не определён. Мой любимый пример – система аутентификации, авторизации, и распределения прав. Не смотря на (казалось бы) универсальный стандарт ACL, я не встречал ни одного проекта, в котором система прав доступа была бы сделана так, чтобы удовлетворять всех от разработчиков до клиентов. Если у вас нет возможности воткнуть какой-то готовый модуль и успокоиться, то единственный вариант – принудить команду запилить конкретное относительно нормальное и легко расширяемое (в будущем) решение. Иначе холивар вырастет на месяц.

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

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

По какому варианту пойти – вам должно быть очевидно. И очевидно, что по такой задаче бесполезно записывать в трекер что-то большее чем заголовок “Внедрить подсистему разграничения прав доступа”.

Резюме:

Автор этих строк использует простое правило: если результат формализован и нельзя сделать прямо сейчас – записывать. В иных случаях – на%уй. Как действовать вам – зависит от вашего проекта и команды. Выберите способ, с которым команда будет наиболее продуктивна, и действуйте по нему.

Проектирование VS Прототипирование: холивар или реальное решение?

Холивар проектирования против прототипирования в больших проектах – это палка о двух концах. На одном из которых – консервативные приверженцы махрового энтерпрайза с каскадным (waterfall) подходом “Спроектируй-запланируй-отрисуй-закодируй-протестируй”, на другом – ярые фанаты Agile и всякого там “XP” с идеей “лучший прототип – это быстро сделанный и запущенный проект”. Continue reading “Проектирование VS Прототипирование: холивар или реальное решение?”