Понимание того, почему определенные функции не реализуются, часто может оказаться сложной задачей. Руководство может винить технические команды, в то время как технические команды указывают пальцем на руководство. Тем временем бизнес оказался посередине, пытаясь выявить первопричину и добиваясь результатов независимо от обстоятельств. Этот сценарий обычно возникает после значительного роста компании или когда предыдущие проблемы, которые раньше было легко исправить, со временем остались без внимания. Распространено заблуждение, что все проблемы в технологической компании являются чисто техническими; Это далеко от правды. В этой статье я опишу области внутри организации компании, которые могут существенно препятствовать реализации функций. Я также предложу направления для расследования, чтобы выявить коренные причины, которые затем можно будет передать на более высокий уровень или устранить в пределах вашего уровня полномочий. Крайне важно понять нашу рабочую среду, прежде чем вносить какие-либо изменения или улучшения. Хотя на эту тему написано множество познавательных книг, не все подходы подойдут каждой компании. Это не свидетельство того, что вы делаете что-то неправильно, а, скорее, признание уникальности каждой компании. Важно отметить, что представленные здесь идеи в первую очередь связаны с разработкой программного обеспечения и наиболее применимы к компаниям или отделам с 50 и более сотрудниками. Организационная структура Прежде всего, поймите размер и структуру вашей компании. Определите различные отделы и уточните свои ожидания от каждого. Оцените, нужны ли все эти отделы. Создайте диаграмму организационной структуры с подробным описанием каждого отдела и их ролей, чтобы вы понимали, чем они занимаются и почему они существуют. Часто каждый отдел состоит из нескольких команд — их также включите в свою диаграмму, но пока не описывайте, просто оставьте названия команд. По мере роста компаний организационные структуры могут усложняться, что затрудняет отслеживание прогресса. В такой сложности вы можете упустить из виду первоначальную причину создания определенных отделов или команд. Некоторые группы могли быть созданы для решения проблем, которые больше не актуальны. Вот как это может выглядеть на высоком уровне. Что будет дальше, когда у вас будет четкая диаграмма вашей организационной структуры? Иерархия сотрудников Далее важно наметить иерархию ваших сотрудников. Понимание того, кто кому отчитывается и почему, имеет решающее значение. Линейным менеджерам необходимо эффективно общаться со своими подчиненными, независимо от того, управляют ли они крупным бизнес-подразделением или небольшой командой. Коммуникация должна быть четкой, как на техническом, так и на деловом языке, поскольку обработка обоих может оказаться сложной задачей. В более крупных компаниях могут быть непосредственные и функциональные менеджеры с отдельными сферами ответственности, которые должны быть четко представлены в вашей иерархической диаграмме. Иерархия сотрудников не только проясняет порядок подчинения, но и помогает определить вертикали внутри организации. Вертикали — это иерархические структуры, которые служат общими ресурсами для нескольких отделов, таких как дизайнеры, HR, DevOps и даже разработчики. Хотя вертикали могут быть очень полезными, иногда они могут стать узкими местами, особенно когда разработчики работают над разными проектами и отчитываются перед менеджерами, которые не знакомы с бизнес-целями или техническими проблемами. В результате разработчики не получают должной обратной связи, менеджеры не имеют должного контекста. Поэтому понимание иерархии жизненно важно для выявления и анализа потенциальных проблем или определения приоритетности задач. В конце у вас будет что-то вроде этого. Аннотация Генеральный директор — Главный исполнительный директор CPO — директор по продукту Технический директор — главный технический директор COO — Главный операционный директор ХД — руководитель отдела дизайна ПО — Владелец продукта ОН — руководитель технического отдела ХС — Руководитель отдела продаж ХМ — Руководитель отдела маркетинга Д — Разработчик ПМ — Менеджер по продукту ТЛ — Технический руководитель ЭМ — Инженер-менеджер С — Менеджер по продажам М — Маркетолог Сравните свою организационную структуру со своими линиями подчинения, чтобы получить представление об участии каждого сотрудника в различных видах деятельности. Более того, согласование вашей организационной структуры с иерархией сотрудников может помочь определить, работают ли люди в одних и тех же отделах и командах ради общей цели. Шаблон отображения полностью зависит от вас, но ему может понравиться этот вариант. Обязанности команды Важно четко определить область, в которой работает каждая команда. Если команда работает с кодом, укажите сервисы, которые они используют и которыми владеют. Удивительно, но зачастую они могут быть разными. Определите, работает ли команда исключительно в рамках одного отдела или это команда платформы, работающая над основными функциями, используемыми другими командами, без их прямого изменения. Может оказаться очень полезным создание таблицы со следующими столбцами: название команды, отдел, список принадлежащих сервисов, список общих сервисов, которые команда может изменять, но не владеет (в идеале таких сервисов не должно быть) и краткое описание. . Эта таблица поможет вам определить, работают ли несколько команд над одной и той же кодовой базой, что приводит к конфликтам, или нет ли ясности в отношении их областей ответственности. Это также может показать, занимается ли команда в первую очередь исправлением ошибок или занимается различными задачами без четкой цели. Такой уровень детализации имеет решающее значение для выявления совпадений, конфликтов и пробелов в обязанностях команды, обеспечивая более плавное сотрудничество и более эффективное выполнение проекта. Обязанности сотрудника Помимо описания команд, важно понять общие позиции сотрудников и подготовить подробное описание их обязанностей. Часто то, что предполагает руководство, может существенно отличаться от того, что на самом деле делают сотрудники. В индустрии разработки программного обеспечения существуют различные позиции, и ожидания могут сильно различаться от компании к компании. Например, роли инженерного менеджера могут сильно различаться, не говоря уже о таких ролях, как менеджеры по доставке, специалисты по данным, архитекторы, технические руководители и т. д. В некоторых компаниях можно ожидать, что один человек будет выполнять несколько ролей. Очень важно установить четкие ожидания для каждой позиции. Такая ясность не только помогает правильно отслеживать действия, но также гарантирует, что сотрудники понимают, чего от них ожидают, а что выходит за рамки их компетенции. Это касается всех должностей внутри организации. Четкое определение ролей помогает предотвратить дублирование, уменьшить путаницу и гарантировать, что каждый работает над достижением общих целей эффективным и организованным образом. Процесс доставки функций К настоящему времени у вас должно быть четкое представление о структуре вашей компании, иерархии сотрудников и их обязанностях. Хотя все может показаться запутанным, цель состоит в том, чтобы сначала понять текущее состояние, прежде чем вносить какие-либо изменения. Теперь пришло время описать процесс доставки функций — как бизнес-функции переходят от первоначальной идеи к производству. Пожалуйста, не сосредотачивайтесь здесь на технических аспектах, таких как CI/CD, а на потоке от бизнеса к разработчикам, предполагая, что разработчики пишут код и развертывают его непосредственно в производстве. Цель состоит в том, чтобы выявить любые проблемы в вашем процессе, от бизнеса до команды, и увидеть, насколько хорошо сотрудники справляются с ними. Учитывайте следующие аспекты: Как часто вы планируете новые функции и распределяете работу по каждому отделу и командам? Как вы устанавливаете и измеряете ключевые показатели эффективности? Используете ли вы вехи? Кто занимается их первоначальной подготовкой? Как вы их планируете с командой? Кто координирует процесс планирования и исполнения? Вы действительно гибкая компания? Используете ли вы такие платформы, как SAFe, Prince2 или PMP, или у вас есть что-то индивидуальное, подходящее именно вам? Как вы справляетесь со сложными межкомандными задачами и контролируете прогресс? Есть ли у вас структурированный подход или вы полагаете, что все каким-то образом разрешится? Помните, каждый уровень управления и отчетности добавляет сложности и неопределенности, независимо от направления. В конечном итоге ваша диаграмма процесса должна отвечать на один простой вопрос: «Как?» Вы можете поиграть с шаблонами и настроить их под свои нужды. Вот пример процесса доставки на очень высоком уровне без ключевых игроков, которые регулируют доставку, но с указанием сроков. Если вы не знаете, как создать эту диаграмму, рассмотрите возможность использования BPMN (модель и нотация бизнес-процесса) или более простого формата, такого как прямоугольники и линии, чтобы обеспечить ясность и понимание между всеми заинтересованными сторонами. Главное, чтобы процесс был ясным и понятным. Соберите обратную связь После того, как вы наметили структуру компании, иерархию сотрудников, команды и должностные обязанности, а также процесс реализации, поделитесь всеми своими выводами с организацией и проведите опрос, желательно анонимный. Этот базовый показатель показывает, как работает ваша компания. Хотя вы могли подготовить этот обзор самостоятельно или делегировать некоторые задачи, вполне вероятно, что разработчики, дизайнеры и аналитики не принимали в нем непосредственного участия. Их отзывы имеют решающее значение для оценки точности ваших выводов. Попросите сотрудников оценить качество вашей документации. Что они думают о процессе доставки? Действительно ли это отражает то, как все делается? Где они видят препятствия? Ожидайте множество жалоб и отзывов, которые помогут вам уточнить ваши выводы, чтобы они лучше соответствовали реальности деятельности компании. Эта обратная связь жизненно важна, поскольку контекст часто теряется из-за нескольких уровней иерархии, а сбор данных со всех уровней обеспечит более четкое и точное представление об организации. Оценить результаты Теперь, когда у вас есть подробное описание того, как работает ваша компания или отделы, вы можете приступить к анализу и поиску потенциальных проблем. Этот базовый уровень обеспечивает четкую отправную точку для понимания и решения проблем. Вот некоторые области, на которых следует сосредоточиться: Структурированы ли ваши отделы? Являются ли четкими линии отчетности? Могут ли линейные менеджеры действительно предоставлять обратную связь относительно своей сферы ответственности? Существует ли путаница или неопределенность при преобразовании бизнес-требований в технические задачи? Есть ли зависимости от других команд, которые вызывают задержки во время разработки? Занимаются ли сотрудники деятельностью, выходящей за рамки их основной сферы ответственности и мешающей выполнению основных задач? Насколько иерархия сотрудников соответствует структуре команды? Эффективна ли иерархия отчетности или существуют пробелы в коммуникации и контексте? Работают ли над одними и теми же сервисами разные команды, что приводит к конфликтам и трате времени на принятие решения о том, кому принадлежит задача? Существуют ли какие-либо команды или отделы без четко определенных обязанностей или без ключевых игроков? Некоторые команды не интегрированы ни в один отдел? В конце вы можете подготовить список реальных проблем, с которыми сталкивается ваша компания, и над этим вы будете работать. Расставьте приоритеты: от критических, требующих немедленного взаимодействия, до улучшений, которые «хорошо бы иметь». Как внести изменения Вы можете задаться вопросом: «Все это звучит здорово, но как мне на самом деле улучшить ситуацию?» Это хороший вопрос, и честный ответ зависит от конкретных проблем, которые вы выявили, и потребностей вашего бизнеса. Однако один важный совет — не пытайтесь изменить все сразу. Вместо этого вносите небольшие изменения постепенно, оценивайте результаты и повторяйте итерации. Помните, что гибкий подход работает не только при разработке программного обеспечения, но может применяться к любому типу организационных изменений. Вот несколько шагов, которые помогут вам в процессе улучшения: Убедитесь, что сотрудники точно знают, в чем заключаются их обязанности, а что выходит за рамки их обязанностей. Создайте четко определенные отделы или домены и назначьте определенные команды для каждого домена. Определите четкие зоны ответственности и сведите к минимуму дублирование отделов и команд. Подумайте о том, чтобы ознакомиться с подходом «Командные топологии», который представляет собой команды, ориентированные на платформы, ориентированные на потоки, обеспечивающие возможности и сложные подсистемы, для охвата различных аспектов разработки программного обеспечения. Просмотрите и скорректируйте иерархию сотрудников, чтобы она соответствовала вновь созданным доменам и командам. Обеспечьте четкую структуру отчетности и простоту отслеживания прогресса. Выберите методологию или структуру, которую вы будете использовать для предоставления функций и отслеживания результатов. Тестируйте изменения в любом отделе, желательно не критичном, и оценивайте влияние, совершенствуйте свой подход на основе отзывов и результатов. Постоянно совершенствуйтесь, применяя выбранный образ мышления к организационным изменениям. Следуя этим шагам, вы сможете внести осознанные, постепенные изменения, которые постепенно повысят эффективность и результативность вашей организации. Краткое содержание Я стремился осветить общие проблемы, которые могут возникнуть в любой компании или отделе. Я намеренно избегал рекомендаций конкретных рамок или подходов, поскольку каждая компания имеет уникальные цели и структуры, и очень важно решить, что лучше всего подходит именно вам. Опять же, легко возложить вину на разработчиков, но помните, что они могут не знать о бизнес-приоритетах или быть заблокированными из-за неясного процесса доставки. Иногда бизнес сам неосознанно создает блокировщики. Надеюсь, эта статья поможет сделать первые шаги на пути к улучшению.
