Зависимости, технологии и кто клиент?
Есть несколько закономерностей в поведении команд от небольших до крупных организаций, занимающихся разработкой программного обеспечения. Хотя культура может играть определенную роль в таком поведении, это не меняет того факта, что некоторые из них, как известно, дают лучшие результаты.
Культура может стать препятствием для реализации некоторых из этих моделей поведения. Например, в компании с культурой микроменеджмента менеджеры могут заставить программистов писать краткосрочный код, который им придется переписать через несколько недель. Точно так же менеджеры могут заставить дизайнеров проверять неоптимальный опыт на счастливом пути, но не на неизвестных и потенциально катастрофических путях с побочными эффектами.
Однако культура не меняет цели программного обеспечения, которая заключается в создании ценности для клиента. Кроме того, культура не меняет путь, по которому каждая команда обречена идти, если не понимает, куда идет. В этой статье мы поговорим о 3 способах улучшить компанию, производящую программное обеспечение, для более эффективного создания ценности.
1. Уменьшите прямую зависимость между командами
Если бы половины команд не существовало, смогла бы компания приносить пользу заказчику? Если наиболее важная команда или ее член попадет под автобус, приведет ли это к остановке всей компании или всей команды?
Высокопроизводительные компании позволяют командам владеть всеми частями стека до клиента. Каждая команда владеет бизнес-контекстом, который увеличивает ценность компании. Одна команда не может быть единым целым; они должны быть загадкой.
Вот пример:
Представьте себе социальную сеть, в которой пользователь пытается изменить свой статус. Служба, которая получает команду, сохраняет намерение пользователя, добавляет задание обновления в очередь и возвращает пользователю сообщение о том, что изменение выполняется. Другой сервис, также принадлежащий той же команде, обрабатывает очередь.
Представьте, что сервер, ответственный за обработку очереди, отключен из-за сбоя. Команда, отвечающая за обновление статуса пользователя, не может достаточно быстро восстановить отключение. В этом случае другие члены группы могут просмотреть очередь и обновить базу данных вручную с помощью сценария SQL.
Команда, отвечающая за обновление статуса пользователя, также может иметь отдел поддержки. Отдел поддержки встроен в эту же команду, так что они могут отвечать на звонки в службу поддержки от пользователей, жалующихся на время, необходимое для изменения их статуса. Наличие отдела поддержки, встроенного в одну команду ближе к программистам, может сократить дистанцию общения и предотвратить разрыв между программистами и заказчиком.
Например, ручное обновление базы данных с помощью сценария SQL не масштабируется до размера Facebook. Однако возможность вносить изменения вручную, если это необходимо, является доказательством того, что служба обновления статуса не имеет прямых зависимостей от службы изображений профиля. Таким образом, разные команды могут владеть каждой из этих служб и работать независимо.
Возможность запускать обновления вручную - это эффективная лакмусовая бумажка, позволяющая проверить, являются ли ваши команды независимыми или нет. Это также позволяет восстанавливать работу после сбоя, не забрасывая пользователя всевозможными ошибками.
Если служба обработки заданий не работает, за эту службу отвечает одна группа, которая при необходимости может запускать задания вручную.
2. Смотрите на технологии как на улучшение реальности
Если бы программного обеспечения в вашей компании не существовало, смогли бы клиенты получить желаемую ценность, хотя и неудобно?
До появления приложений для общения в реальном времени люди разговаривали друг с другом лицом к лицу. Вы все еще можете сделать это сегодня. Никто не мешает вам сейчас навестить друга.
Однако поддерживать связь с друзьями без технологий, если они живут далеко, обходится дорого: топливо, время, авиабилеты, билеты на автобус. Появление социальных сетей и приложений для общения в реальном времени не изменило основную реальность того, как люди общаются. Они просто улучшили существующую реальность с помощью технологий.
Технологии не важны для создания ценности. Однако важно максимизировать создание ценности. Технологии должны улучшать ваш бизнес, а не делать его зависимым от технологий. Команды должны быть способны создавать ценность без технологий при очевидной цене за эффективность.
Технологии не важны для создания ценности. Однако важно максимизировать создание ценности.
3. Поймите, кто ваш клиент
Каждому человеку, работающему в компании, жизненно важно понимать, кто получает пользу от своей работы: клиент. Если вы не знаете своего клиента, значит, у вашей работы нет цели; вы не можете получить обратную связь от тех, кто использует код, который вы пишете, чтобы убедиться, что ваш код движется в правильном направлении.
У клиента тоже может быть много лиц.
Если вы работаете в небольшой платежной компании, клиентами являются другие компании, которые платят за платежное решение. Если вы работаете в большой компании, клиентами могут быть другие команды, использующие API обслуживаемой вами службы.
Клиенты всегда рядом, даже если они не оплачивают вашу работу напрямую.
Если вы пишете код для библиотеки с открытым исходным кодом, даже если никто не платит за вашу работу, клиентами становятся разработчики, которые используют эту библиотеку, а не сопровождающие проекта. Если вы работаете в системе внутренней сети сотрудников компании, клиентами являются другие сотрудники, а не стандартные клиенты компании.
Ваш клиент также может быть менеджером. Это зависит от того, чем вы занимаетесь.
Если вы создаете наблюдаемость продукта, чтобы менеджер по продукту мог принимать более правильные решения, тогда клиент - это менеджер по продукту. Если руководитель группы просит вас запустить имитацию спринта с использованием отслеживаемой скорости текущей команды, то вашим клиентом является руководитель группы.
Знание своего клиента - это залог максимальной эффективности обратной связи. Нет смысла получать отзывы от кого-то, кто не является конечным пользователем вашей работы.
Понимание клиента имеет первостепенное значение. Без них ваша работа бесполезна.
В итоге
Уменьшите прямую зависимость между командами. В противном случае вы рискуете столкнуться с перебоями в работе, из-за которых вся ваша организация отключится.
Смотрите на технологии как на улучшение реальности. В противном случае, когда произойдет такое отключение, не будет отката от вмешательства человека.
Поймите, кто ваш клиент. Без понимания своего клиента вы не получите адекватной обратной связи от тех, на кого влияет написанный вами код. Используйте отзывы своего клиента, чтобы сначала создать правильное, а не сосредотачивайтесь только на создании правильного.
Не пугайся. Отсутствие этих методов не разрушит вашу компанию и не помешает ей стать прибыльной. Возможно, вы все еще сможете создать достойную организацию с разумным доходом. Однако, если вы заботитесь о том, кто ваш клиент, о ваших рабочих зависимостях и о том, как технологии улучшают ваш бизнес, вы, скорее всего, превзойдете все, что разумно.
Все дело в том, к какому стандарту вы стремитесь.
Все дело в том, хотите ли вы создать что-то отличное или просто достаточно хорошее.
Спасибо за прочтение. Если у вас есть отзывы, напишите мне в Twitter, Facebook или Github.
Благодарим Ави Кесснер и Мэтт Смит за их полезный вклад в этот пост.
Хотите пообщаться лично? Вы можете найти меня на встрече разработчиков программного обеспечения в Сиднее.
