Ошибки команд или как стать лучше

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

Рассматриваются только команды, которые

1. Являются командой. 1 человек - это не команда, 2 – тоже маловато
2. Не проектные команды. Многие ошибки применимы и к проектным командам, но упор сделан на команды фикси, которые по сути являются 2-3 линией поддержки
3. Вопрос индивидуальной компетенции опущен. Команда из новичков не может быть сверхэффективной, команда же из звезд может быть посредственной

Проблемы также имеют ограничения:

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

Если вам есть что дополнить или с чем-то вы не согласны – добро пожаловать в холивар в комментарии. Если вы нашли ошибку, опечатку и косяк в оформлении – напишите мне в личку.

1  Рисковые парни

Увольте их.

1.1 Нет бекапов

Что будет, если внезапно РБ (рабочая база) перестанет существовать?

Попробуйте устроить экзамен сотрудникам, которые отвечают за работоспособность РБ (Сис. админам, администраторам СУБД или отделу 1С). 

Вводная: 

1. Файл БД поврежден и восстановлению не подлежит 
2. Диск, на котором крутилась БД форматнулся и доступа к нему нет 
3. Молния ударила в серверную и все сервера, которые стояли по соседству с сервером БД, недоступны

Какую задачу, за какое время и бекап какой давности получится развернуть?

1.2 Нет хранилища конфигурации

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

2. Слабая команда

Они постоянно в мыле, постоянно что-то переделывают и исправляют. Любую простую задачу сделают через месяц и неправильно

2.1 Нет списка задач

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

Что именно использовать в качестве списка задач – каждая команда решает сама. Чаще всего пишут что-то свое, кто-то использует ексель или гуглотаблички, кто-то использует что-то чужое, типа Redmine, Trac, JIRA итд.

Хорошей практикой является визуализация списка задач с помощью доски.

2.2 Разработка в файловой, если РБ в клиент-сервере

Или другими словами – большое различие между архитектурой продукционной среды и архитектуры среды разработки. То, что работает в одной, может не заработать в другой. Ошибка передачи мутабельного значения в РБ – не очень приятная штука.

2.3 Конфигурация не поставлена на поддержку

Если захочется обновить конфигурацию – будут большие проблемы

2.4 Разработка ведется без учета возможности обновления

Даже если конфигурация поставлена на поддержку, то это не гарантирует легкости в обновлении. Облегчить обновление могут такие правила, как: префиксирование своих объектов, использование обрамляющих комментариев, максимальное сохранение типового кода и т.д.

2.5 Регламенты СУБД не настроены

Отсутствие регламентов СУБД обычно означает, что о производительности никто не задумывается. Документ проводится 10 минут? А что вы хотели? Система сложная, много всего обсчитывает. Появление регламентов навряд ли ускорит проведение до нескольких секунд, но их отсутствие - явный признак пробела в знаниях.

2.6 Нет тестирования

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

3.Обычная команда

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

3.1 Не выполняются стандарты и методики разработки

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

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

Использование стандартов разгружает мозг и позволяет не выдумывать каждый раз какое-либо простое архитектурное решение, а использовать гарантированно неплохое. Оно позволяет не допустить массу ошибок в разработке и при этом программист даже не будет задумываться о них. Вот запрещено в модуле объекта использовать Предупреждение() и программист просто его не использует и каждый раз не думает, а почему нельзя и что может случиться, если все же напишу?

При использовании стандартов качество и скорость разработки сразу улучшаются на порядок.

3.2 Изобретение велосипедов

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

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

3.3 Используются Выполнить(), Вычислить() и внешние обработки в РБ

Есть «Хорошие» внешние обработки и использование выполнения исходного кода, например, внешние печатные формы, внешние отчеты, сложнонастраиваемые методы получения данных в планировании… Но, если рабочие места или ключевая логика выполнена на внешних обработках – это привносит кучу проблем.

• Внешний код не ловится проверками кода. Переименовали мы объект, протестировали всю конфигурацию, а после обновления отвалились обработки
• Внешние обработки приходится отдельно версионировать и следить, чтобы все использовали актуальную. Нужно отдельно следить какая версия в разработке, какая на тесте, а какая работает в РБ
• Если у пользователя возникает ошибка, то в журнал регистрации падает «Форма {25} тут пошло что-то не так». Выяснить источник можно только после общения с пользователем
• Внешний код на порядок сложнее оптимизировать
• На внешнюю обработку/отчет сложнее сделать ссылку в интерфейсе/форме
• Внешний код несет угрозу безопасности

3.4 РБ подключена к хранилищу разработки или не имеет хранилища в принципе

Если РБ подключена к хранилищу разработки, то как-нибудь в РБ уйдут недоработанные вещи и придется очень долго это вычищать или экстренно доделывать. Лучше не подключать РБ к хранилищу, а переносить изменения сравнением/объединением – тогда будет понятно, что выкатывается и что может отвалится. А еще лучше использовать отдельное хранилище и подключенную к этому хранилищу спец. базу для обновления. Это позволит разделить моменты выката изменений с их контролем и непосредственным обновлением РБ. Откатиться на предыдущую сборку становится проще, и история выката сохраняется.

3.5 Нет выделенной техподдержки

Если есть программист, который зарабатывает 100 т.р. и к которому обращаются пользователи с возникшими проблемами, затруднениями или рутиной задачей (завести нового пользователя, поменять реквизит в закрытом документе и т.д.), то этот программист сможет сделать не очень много задач. Но если взять нового сотрудника на 30 т.р., который будет делать простейшие задачи, то производительность программиста может вырасти в 2-10 раз

3.6 Нет аналитика/консультанта/РП

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

3.7 Нет оцененного плана работ (беклог, спринтбеклог)

Развитие списка задач. Кроме того, что есть задачи, очень хорошо бы иметь приоритеты у этих задач (их назначает бизнес) и иметь оценки этих задач (их назначает команда). Имея приоритеты и оценки, уже можно планировать работы и отвечать на вопросы «А когда вы сделаете мою хотелку?». При оценке задачи приходится подумать, а что нужно сделать, чтобы ее выполнить, и очень часто всплывают неочевидные вещи, которые нужно уточнить, которые оказываются сильно трудоемкими или которые можно купить на Инфостарте, сэкономив пару недель разработки. Чем раньше это всплывет, тем лучше.

3.8 Нет обратной связи с пользователями

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

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

3.9 Не используется топовое железо при разработке

Чем лучше железо, тем больше времени тратит программист собственно на разработку и тем выше его эффективность. Что происходит, когда комп подвисает, выполняя какую-либо операцию?  Секунд 5 программист ждет, пока это закончится, а потом он решает скоротать время и открывает браузер. Минут 15 работы вылетает сразу. А ведь программист не хотел лезть в интернет, он просто решил скоротать время из-за медленной работы ПК. Прирост в эффективности в 10% отобьет топовый комп для разработчика меньше чем за год.

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

Хотите быстро поднять эффективность и мотивацию команды – обновите им компы и сервера.

Сюда же отнесу более комфортные условия работы – отдельный тихий офис, кондиционер, приятная обстановка, большая доска для рисования и т.д.

3.10 Нет простейшей базы знаний

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

3.11 Нет саморазвития

Если в команде никто не старается узнать что-то новое, не читает статей, книг, не следит за обновлениями стандартов и методик, не смотрит код в типовой – обстановка медленно превращается в болото, а мотивация падает. Особенно дело обостряется, когда программист 2 года просто сидел на попе ровно, ничего не изучал и не повышал уровень своих навыков и знаний, и тут он решил потребовать повышения зарплаты.

4. Хорошая команда

Удивляет скоростью внесения изменений. Большинство пользователей довольны системой.

4.1 Неритмичный выпуск обновлений

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

4.2 Нет скриптов на повторяющиеся действия

Если какое-либо действие может выполнить компьютер сам, то пусть выполняет. Автотесты, автобекапы, авторазворачивание копии РБ – это все экономит время высокооплачиваемых специалистов, а также сильно снижает вероятность что-либо забыть или сделать не так. Бекапы ведь все всегда делают перед любым обновлением?

4.3 Нет двойного чтения кода

Это когда любую строчку кода, нового или измененного, прочитало как минимум два программиста. Один программист при написании, а второй одним из следующих способов:

• Парное программирование – все о нем знают, но навряд ли кто пробовал. Заявлено, что качество кода повышается, а скорость даже выше, чем, когда 2 программиста работают по отдельности. Думаю, прирост скорости связан только с тем, что отвлекаться на что-либо, кроме программирования, становится неудобно.
• Аудит кода – берется кусок кода на 500-2000 строк, собираются несколько программистов, в том числе автор куска кода, и обсуждают этот фрагмент, выявляя ошибки, плохой стиль, хорошие идеи и т.д. Такой формат очень и очень быстро поднимает уровень слабых программистов до уровня лучших из участвующих.
• Проверка кода перед помещением в основную ветку – ответственный за основную ветку проверяет весь код, который поступает в основную ветку, и не принимает тот код, который ему не понравился по какой-либо причине.

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

Также двойное чтение кода способствует улучшению коллективного владения кодом.

4.4 Не используется автоматическое тестирование

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

4.5 Не проводятся мероприятия по повышению юзабилити

Сюда относится все то, что обеспечивает более удобную работу пользователей. Для этого нужно уметь ставить себя на место пользователя, знать основы разработки пользовательского интерфейса и юзабилити, наблюдать за тем, как работают пользователи (по-научному - юзабилити тестирование), проектировать сценарии работы и многое другое.

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

Еще один важный момент – пользователи работают с интерфейсом совершенно не так, как это делаете вы. Если вы сделали суперудобную форму, в которой можете работать легко и непринужденно, то попробуйте понаблюдать за пользователями. Вы можете быть сильно удивлены их подходом: они не умеют пользоваться буфером обмена, работают только мышкой, не знают половины типовых команд, не используют 90% функционала и вообще не понимают, зачем они тут что-то делают. А еще может оказаться, что на рабочем месте нет мышки и монитор всего лишь 14 дюймов.

4.6 Не используются сервисы для мониторинга продуктовой среды

Жизнедеятельность РБ обычно не входит в обязанности команды разработки, но если там что-то перестало работать – кого обвинят в первую очередь? А через сколько в команде узнают, что не работает регламентное задание?

Так же контроль за серверами разработки позволяет избежать простоев и проблем при внезапно закончившемся месте на диске

4.7 Нет полноценной базы знаний

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

4.8 Нет ретроспективы

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

Многие считают, что самая важная практика в Scrum – это ретроспектива. Если выполнять ее регулярно и приводить в жизнь все те решения, что были придуманы – команда очень быстро растет.

4.9 Нет прагматизма в работе

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

Эффективная команда – прагматична. Она делает только то, на что затраты окупаются. Можно даже по каждой задаче из списка проставлять коэффициент возврата на инвестиции (ROI). Чем быстрее отобьется инвестиция, тем быстрее стоит выполнить задачу.

5. Команда мечты

1. Их не существует.
2. Высокоэффективна
3. Предсказуема
4. РБ работает без сбоев
5. Изменения быстро и безболезненно приживаются