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

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

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

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

Резкий переход не предвещал ничего хорошего для будущего компании, и вскоре после этого я ушел.

Думаю, это было мое первое знакомство с понятием «билеты», и оно мне не понравилось. Что я хотел бы сделать с вами сегодня, так это поделиться с вами тем, как я нашел способ сбалансировать контроль и творчество.

Как задействовать креативного сотрудника?

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

Я осторожно использую здесь слово «радость» — создавать вещи радостно, а радость можно легко убить. Ваша первая задача должна состоять в том, чтобы создать радость достижения в вашей команде. Вы можете сделать это, только отмечая успехи и поощряя членов команды; не ругая и не ограничивая их. Что вы должны сделать, так это взять какой-то компонент из того, что они сделали, и поощрить его к лучшему.

В реальном мире вы должны принять «промах» и превратить его в успех:

  • Художник, работавший со мной над одной образовательной игрой, создал потрясающее фоновое изображение, которое не соответствовало руководству по стилю игры. Хотя на то, чтобы сделать еще кучу иллюстраций, подобных этому, ушло слишком много времени, мы превратили его в красивый уровень, на котором он не будет выделяться — и он стал основным демо-уровнем, которым хвасталась наша команда по продажам.
  • Инженер создал новый сервисный слой для проекта, который был отменен из-за меняющихся потребностей бизнеса. Мы попросили его задокументировать это и продемонстрировать другим свой стиль кодирования; он превратил его в стандарт для наших проектов следующего поколения, и он живет по сей день.
  • Я нанял стажеров и дал им полезные проекты, которые были связаны с бизнесом, но не критически важны. Некоторые боролись, а некоторые преуспели; но большинство из них оценили возможность владеть чем-то уникальным и попробовать свои силы в создании собственной новой вещи. Со временем мы смогли объединить многие из этих программ в наше основное приложение.

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

Риск отсутствия воспитания

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

Почему инженер покидает компанию после того, как его проект отменен?

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

Водитель автобуса не уходит, когда его автобусный маршрут отменяется. Шеф-повар не уходит, когда меню меняется.

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

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

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

Но билеты нужны

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

Можно сделать билеты совместимыми с творчеством. Давайте посмотрим на общий стиль билета «Как (тип человека), я хочу (особенность или вещь), чтобы (польза или результат)»:

  • Ваши билеты должны быть открытыми, а не запрещать решения. Если творческий человек решает проблему по-новому, это творчество.
  • Вы должны указать в своем билете, кто является лицом, которое получает выгоду. Это клиент? Внутренний разработчик? Партнер? Продавец?
  • Вы должны описать в заявке, какую пользу это лицо получает от проделанной работы. Если польза мала или велика, если эффект мгновенный или постепенный, вы все равно должны документировать его, чтобы ваша команда понимала, как они могут помочь.
  • Если у вас есть справочная информация, историческая информация или что-то еще полезное, это не должно загрязнять историю.

Хороший шаблон, который я использую, таков:

Story:
* As a partner developing a product that uses widgets,
* I want my widgets to have handles on the vertical surface,
* So that I can set the widgets down into the frobbing bin.
Description:
* The OHSA code for widget surfaces is defined in http://example.org
* Alice and Bob wrote handle specifications last year

Но билет — это только часть истории.

  • Поощряйте вашу команду делать больше, чем минимальный объем работы. Когда они оценивают время и усилия, они должны дополнять свои оценки и производить надежную работу, а не работать в спешке.
  • Инженеры должны иметь право писать свои собственные заявки и выполнять свою работу. Инженер всегда должен иметь возможность написать новый тикет и добавить его в микс.
  • Создавайте множество вех на своем пути. У каждой вехи должна быть регистрация, где люди могут увидеть и потрогать свою работу.
  • Каждый раз, когда инженер что-то создает, принимайте это всем сердцем — и предлагайте, как это можно улучшить!
  • Регулярно проводите демонстрации своего программного обеспечения; продемонстрируйте творческие возможности, созданные вашими инженерами.
  • Создавайте компоненты, а не огромные программы, чтобы их части можно было использовать даже в случае отмены.

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