В последнее несколько лет стало модным говорить о правильных процессах: в бизнесе, в производстве и т. д. Но не все понимают что такое "правильные" и к каким изменениям должны привести эти процессы?
В разработке прикладного программного обеспечения тоже должны быть выстроены правильные процессы. Что под этим имеют ввиду? Что такое правильные процессы? Что они должны делать? Каким требованиям отвечать? Об этом мы немного и поговорим.
С начало мое любимое правило, не могу вспомнить, где я его прочитал или услышал, но уверяю они работает на все 100%:
Процессы в разработке программного обеспечения должны приводить к определенным изменениям, для себя я выделил следующие основные :
- Снижение влияния человеческого фактора. Это мой самый любимый, пункт и позже мы на нем остановимся подробнее. Сюда можно отнести: внедрение CI/CD, поддержка и контроль процесса программными средствами, накапливание знаний wiki, ограничение и контроль доступа и много что еще.
- Согласованность действий. Каждый сотрудник знает, что/когда/в каком виде ждут от него, а он от других. Это особенно актуально в командах от 7 человек. Особенно, когда люди делающие одно дело подчиняются разным руководителям. Пример: аналитики, разработчики и тестировщики - часто можно услышать истории, как эти замечательные по отдельности люди, не могут ужиться друг с другом, как пауки в банке на одном проекте. А все по той причине, что в операционнке и дедлайнах забыли о главном - договориться, кто что от кого ждет и в какой срок.
- Прогнозирование результатов. Выработка последовательности шагов, приводящих к ожидаемому результату в понятные сроки. Другими словами, нужно всегда искать кратчайший путь для достижения цели, пытаясь убирать все лишнее, что мешает. Выделять главное, к чему мы стремимся. Но при этом важно не перестараться, что бы не стать похожими на следующий мем. Ниже мы еще раз подробно его разберем.
- Непрерывные улучшения в работе команды. Не дает скучать команде, помогает выйти на новый уровень качества и скорости, при тех же затратах энергии и времени.
Для того чтобы выстроить соответствующие процессы существует множество инструментов: роли, этапы, методологии, управление ожиданиями, people management, активности, артефакты, инженерные практики, личный опыт.
Снижение влияния человеческого фактора
Понятие человеческого фактора пришло в мир из военного дела, если быть точным из авиации — мировая история знает много примеров влияния этого фактора на ход событий в мире. Когда я слышу употребление выражение «да это человеческий фактор», то не сомневаюсь, что речь идет об чьей-то ошибке! Инцидент на бою, что-что забыли сделать и т.д.
Откуда берется человеческий фактор, думаю все мы знаем. А самое главное это неотъемлемая часть природы человека.
Но не все догадываются, что человеческий фактор бывает умышленным. Понятно, когда человек забыл, устал, пропустил, запутался - все это неумышленный человеческий фактор. А бывает так, что человеческий фактор срабатывает из-за преднамеренных действий человека, желающего получить выгоду.
Ниже я сделал небольшую схему классификации человеческого фактора:
Если мы смогли этот фактор выявить и классифицировать, путь и в "первом приближении", значит можно придумать и инструменты, при помощи которых можно снизить влияние этого явления на результат нашей деятельности.
Я часто использую следующие инструменты в работе:
- Установить правила работы, единые стандарты для всех (например, code style), которые будут выполняться всеми в подразделении. Пишите правило просто и понятно, обеспечите доступ к правилам для всех участников процесса. И самое главное разъясните их всем, спросите, как на экзамене случайных людей, как они понимают то или иное и правило... и вы удивитесь... что не все правила понятны с первого раза.
- Откажитесь от микроменеджмента. Микроменеджмент - это зло. Желание отдельных сотрудников контролировать все процессы, а ещё лучше выполнять всю работу, погубит всех, включая этих сотрудников. Даже если ваши подчиненные делают что-то хуже чем вы - это не значит что вы должны выполнять их работу. Вы должны научить, при необходимости натренировать их. И не забывайте, что если вы всегда за всех все делаете, то возможно, ваши сотрудники об этом знают и этим пользуются... подумайте над этим.
- Взаимозаменяемость сотрудников, не должно быть не заменимых людей! А также кусков кода или систем, правила работы с которыми известны только одному уникальному сотруднику. Если у вас это уникальные не заменимые сотрудники есть, то это рано или поздно приведет к одному результату: человек уйдет от вас и у вас будут проблемы или будут вас шантажировать (возможно не намеренно) и у вас будут проблемы.
- Периодическое обучение, это очень важно. Я бы даже сравнил это с инвестированием. Делать обучение можно по разному, например презентация работы разных команд и продуктов, обсуждать нововведения на совещаниях, обеспечивать профессиональный рост сотрудников давая сложные задания.
- Накапливание знаний. Все что вы делаете на работе хорошо известно вашим сотрудникам, но может вызвать большие проблемы но вновь прибывших коллег. Поэтому моей совет, ведите wiki. Пишите туда все от документации по настройке среды разработчика, правила кодирования, инструкция для развертывания системы, заканчивая какими-то специфическими знаниями в рамках проекта (например протоколы совещаний - очень полезно сохранять).
- Ограничить доступ сотрудников к важным данным. Думаю тут можно не комментировать.
- Проверять сотрудников в момент приёма на работу. Люди есть разные, если вы ошиблись и взяли слабого сотрудника - то это пол беды, в большинстве случаев, его можно прокачать или поговорить и ним и объяснить ситуацию, попросив его быть усерднее или иногда задерживаться, если он явно отстает от коллектива. А вот как быть если вы взяли проблемного сотрудника, то есть человека который деморализует коллектив или принципиально не подчиняется руководителю или имеет свое уникальное мнение, которое идет в разрез со всеми членами команды, а может быть и бизнеса? Такого еще и уволить может быть не просто. Поэтому. как правило, если у сотрудника были «приключения» на предыдущем месте работы, то об этом скорее всего можно узнать. И далеко не всегда от его "счастливого" руководителя, который только что, от него избавился;-)
- Постоянная оценка поведения сотрудников. Говорят, раньше на каждого сотрудника в гос. органах вели личное дело, где указывали всё до мелочей, любой действие, которым человек отличился (проступок или достижение). Я тоже рекомендую делать что-то подобное. Если и не вести личное дело))) то как минимум общаться со всеми подчиненными не не только на рабочие темы. Уделяйте совсем немного времени на общение "о жизни". И если вы заметите, что человек резко меняет свое общение, то обязательно нужно выяснить причину. Обычно коллеги или линейный руководитель замечают на ранних этапах.
Согласованность действий
По мере роста команды или количества проектов, у коллектива снижается результативность, резко повышается усталость, время начинает «утекать сквозь пальцы».
Такое часто происходит из-за отсутствия простых правил:
- Распределение ролей - все сотрудники должны знать свою роль. Каждая роль наделена своими полномочиями и обязанностями.
- Утвержденный регламент взаимодействия - понятно, кратко описаны алгоритмы работы сотрудников, коммуникации между ними и результаты работ. Например, результат работы аналитика - заведенная задача, в которой есть описание, на основании которого разработчик может дать оценку.
- Расскажите людям, что они должны делать - часто этим пренебрегают, и не дают достаточных разъяснений сотрудникам, просто рассылают регламент, и все его трактуют самостоятельно.