Мы склонны относиться к новым технологиям, таким как Святой Грааль, маяк света и ответ на все, что является медленным, неэффективным и старым. И это может быть, если это будет реализовано с помощью планирования и предвидения.
Но, хорошо, мы все знаем, как это происходит.
Во время моей работы в правительстве, когда иногда казалось, что мы играем в игру технологического догонялка, в которой невозможно победить, я узнал, что может произойти, когда это предвидение воспринимается как должное. Это немного меньше похоже на Святой Грааль и намного больше похоже на перерасход средств, задержки и запутанные решения в противном случае простых проблем.
Как я узнал, одним из главных ключей к успешному технологическому проекту являются гармоничные отношения между бизнес-командой и технологической командой. По моему опыту, бизнес-команда часто руководила изменениями (нам нужна более сложная система, например, для отслеживания расходов на федеральные гранты), но мы не смогли бы добиться успеха, если бы разработчики и руководители ИТ-проектов не смогли это сделать. бывает. Проекты часто оказывались далеко не гармоничными, в результате они говорили по-разному на разных языках и придерживались совершенно разных ожиданий (например, изменение, которое мне казалось незначительным, часто оказывалось важным для разработчиков).
Но бизнес и технологии могут и должны быть друзьями. Хорошие новости? Достижение гармонии действительно не так сложно. Как и любое сотрудничество, оно связано с частотой и качеством связи, взаимно согласованным набором целей и планом действий по практически неизбежному изменению этих целей. Вот несколько основных рекомендаций по управлению бизнес-технологическим разрывом.
1. Стремитесь согнать требования в первый раз
Думайте о бизнес-требованиях как о проекте. Вы не будете рисовать отрывочный набор чертежей для дома, доставлять их подрядчику и желать ему удачи. Вы не вернетесь на три недели назад к строительству и не попросите его добавить третий этаж и четвертую ванную комнату и, возможно, эркер в гостиной. И вы, конечно, не будете рисовать свои чертежи без участия архитектора и инженера.
Технологический проект не так уж отличается. Он должен быть спроектирован с высокой точностью, и как только начинается разработка, не всегда легко приспосабливаться к изменениям, не затрагивая весь фундамент. Вот почему так важно с самого начала быть как можно более всеобъемлющим и получать необходимую информацию и опыт, чтобы продумать, что потребуется для решения. Опросите конечных пользователей, чтобы понять, с какими проблемами они сталкиваются, и как именно они должны будут использовать новую технологию. Не делайте предположений и не оставляйте какие-либо части планирования на потом.
2. Но признайте, что вы пропустите немного
Тем не менее, я обнаружил, что почти невозможно представить каждую особенность, которая нам нужна на этапах абстрактного планирования. Неизбежно, когда система будет в разработке, мы поймем, что забыли запросить функцию расширенного поиска или кнопку «сохранить и продолжить». Когда мы обращались к разработчикам с просьбой учесть эти новые запросы, мы часто встречали разочарование. Возможно, новое изменение потребует от них отменить работу, которую они уже сделали, и перестроить части решения. Возможно, мы предполагали, что это займет два часа, а на самом деле это займет день.
Возможно, вам не удастся предотвратить эти откровения, которые появятся позже в игре, поэтому лучшее, что вы можете сделать, - это создать буфер для их размещения. Добавьте дополнительную неделю к вашему первоначальному графику и дополнительные 5-10% к вашему бюджету. Многие организации, осознавая, как часто меняются ожидания, приняли гибкий подход к разработке, внедряя технологии поэтапно, чтобы обеспечить периодическую переоценку. Независимо от вашего подхода, не делайте ошибку, думая, что вы подумали обо всем с самого начала. Это почти никогда не происходит.
3. Знайте, что сфера ползет, когда вы видите это
По мере продвижения проекта и выявления новых потребностей важно различать те, которые вам действительно нужны, и те, которые вам нужны. Просьба к разработчикам учесть каждый звонок и свист, который может придумать ум, обычно приводит к бесконечным проектам и чрезмерно сложным конечным результатам. Каждый новый запрос, прежде чем он будет сделан, должен иметь приоритет.
Когда вы рассматриваете функцию, задайте себе несколько основных вопросов: будет ли система работать без нее? Сколько времени потребуется для реализации и сколько выгод в конечном итоге будет доставлено конечному пользователю? Если мы подождем до следующей версии, чтобы решить эту проблему, что-нибудь будет потеряно? Это упражнение по расстановке приоритетов, и все может быть присвоено состояние высокого, среднего или низкого. Если оно низкое, поместите его на переносную парковку - я слышал о компаниях, у которых есть документы с «запросами на разработку мечты», к которым каждый может добавлять идеи, а инженеры могут просматривать на досуге. Его всегда можно пересмотреть как часть пакета улучшений, которые будут сделаны после того, как проект будет запущен и успешно запущен.
4. Развивайте общий язык
В основе любой новой системы лежит ряд бизнес-целей. Это позволит вам собирать больше данных, оптимизировать существующий процесс или предлагать новые услуги своим клиентам. Очень важно, чтобы бизнес-команда и технологическая команда сели перед началом любой работы и сообщили об этих целях. Бизнес-цели не должны теряться в море технических разговоров, и они должны твердо помнить на каждом этапе работы.
Разработка общего языка означает не только установление коллективных целей, но и отслеживание прогресса таким образом, чтобы это работало для всех. Бизнес и технологии могут использовать различные инструменты для измерения своей работы, но должен быть хотя бы один общий взгляд на прогресс. Это может быть так же просто, как план проекта или электронная таблица с согласованными полями, такими как даты, цели и процент выполнения, так что у каждого есть доступ к статусу каждой задачи, которую нужно выполнить. Цель состоит в том, чтобы избежать ситуации, в которой бизнес-команда считает, что они на полпути, а техническая команда говорит, что они всего четверть - каждый должен иметь одинаковое понимание того, что было сделано и что осталось сделать.
Вы можете говорить в бизнес-планах и PowerPoints, а они могут говорить в коде, но если вы не будете общаться с самого начала, вы никогда не сделаете это из Babel. Успешный технологический проект - это встреча умов - не только в начале, но и на каждом этапе пути. Признайте свои предположения и постарайтесь не делать слишком много. Чем меньше пропасть между бизнесом и технологиями, тем легче будет пересечь мосты вместе.
