Как составить последовательный процесс работы

Построение процессов с нуля: от хаоса к порядку

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

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

Исходные данные нашего отдела: небольшая (5–10 человек), частично распределенная (некоторые сотрудники работают удаленно, некоторые в офисе) продуктовая команда с заказчиками внутри самой компании. Веб-проекты. Нет специалистов по системному администрированию внутри отдела, но есть занимающиеся этим отделы в компании.

Коммуникации в команде

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

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

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

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

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

Для начала мы завели чат в Telegram. Но потом, в связи с ростом команды, мы поняли, что в одном чате нам уже тесно, и перешли в Slack. Там мы разбили общий поток на тематические каналы и установили четкие правила — по каким поводам в какой канал писать. Это помогло избежать смешения полезной информации и флуда.

Плюс, переход на Slack дал нам некоторые приятные возможности для автоматизации и интеграции с другими сервисами, типа системы управления репозиториями или багтрекера.

• Аудио- и видеозвонки — Skype for Business.
• Задачи ведем в Jira.
• Базу знаний храним в Confluence.

Планирование, исполнение и контроль задач

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

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

Для борьбы с этим мы разработали и внедрили свою культуру ведения задач:

• Работа не должна выполняться, пока не заведена соответствующая задача. Это помогает держать всегда актуальной историю развития проекта и работы команды.
• При работе с задачей необходимо своевременно менять ей статусы. В нашем случае хватает четырех статусов: «To do» — стартовое состояние задачи, «In progress» — задача, которая находится в процессе выполнения, «On hold» — задача, которую начали выполнять, но работы приостановлены (ждем какой-то дополнительной информации), «Done» — задача готова. Готовность задачи должен так или иначе подтвердить заказчик или менеджер внутри команды.
• Со временем количество задач и проектов сильно увеличилось, так что общий список работ мы разбили на отдельные подпроекты, и задачу следует заводить согласно этому списку подпроектов.
• Задаче необходимо назначать приоритет. Это помогает понять, какие задачи в каком порядке требуется выполнять, чтобы причинить проекту максимальную пользу.
• Периодически проводится ревью задач и их приоритетов. Так как проекты живут и развиваются, а планы бизнеса иногда меняются, то со временем некоторые задачи становятся менее или более актуальными или вовсе требуют своего удаления.
• Некоторые ключевые обсуждения по задачам, которые производились устно или письменно в чате, требуют фиксации финального решения в самой задаче, чтобы при ее выполнении мы всегда видели самую актуальную информацию о ней и о ее истории. Нередко бывает, что изначальная постановка задачи после ряда обсуждений трансформируется в нечто совсем иное, и нам нужно следить за этим.
• Если внутри команды задача передается от одной группы специалистов к другой, то передающая группа обязана зафиксировать в ней все необходимые артефакты знаний, которые надо передать следующей группе. Например, группа дизайна перед передачей задачи в группу разработки должна прикрепить макеты и всю необходимую для разработки документацию. Это позволяет избежать лишних вопросов, отвлечений и переключений контекста.
• Прикрепление коммитов к задачам. С помощью некоторых правил именования коммитов у нас автоматически привязываются к задачам ссылки на коммиты в GitLab. Это сильно помогает в разработке понимать, кто, что, как и когда делал по данной задаче. И в обратную сторону, по правильно именованным коммитам всегда можно найти задачу, содержащую причину внесенных изменений.

Коммуникации с заказчиком

Следующая категория трудностей, которую нам было необходимо разрешить, — работа с заказчиками. Первое, что нам предстояло искоренить, — постановка задач на словах. Если мы внедрили культуру письма внутри отдела, то пришло время распространять ее и на внешние контакты.

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

В таком подходе кроется сразу несколько проблем:

• То, что сказано на словах и жестами, забудется (хотя бы частично) примерно завтра, в лучшем случае послезавтра. Речь даже не столько о каких-то мелочах, сколько об опасности совсем забыть о задаче. При этом невозможно никак подтвердить, что ты кому-то ее ставил или что кто-то тебе обещал сделать хоть что-то.
• Обычно такая постановка задачи довольно сумбурна, и в ней отсутствуют какие-либо глубокие детали. В результате очень сложно уточнить недостающую информацию.
• Как обсуждалось ранее, постановка задачи на словах потакает тлетворному нежеланию учиться формулировать свои мысли письменно так, чтобы поняли другие люди.

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

Далее мы столкнулись с еще одной важной проблемой: заказчику сложно сформулировать задачу. Заказчик не всегда достаточно компетентен (а вернее, практически всегда недостаточно компетентен) в формулировании ТЗ для технической команды. И это нормально. Нельзя игнорировать и человеческий фактор: заказчику может быть банально неловко и неудобно приходить с просьбой к команде, когда он сам еще не смог до конца ее сформулировать. Один из критериев зрелой профессиональной команды — это умение помочь заказчику в выявлении его проблем, требований и решений.

Часто бывает, что заказчик, вместо того чтобы прийти с проблемой, приходит с просьбой о реализации уже выдуманного им решения. Чтобы не удивлять ни себя, ни заказчика результатами работы по ТЗ, составленному «на салфетке», мы создали базовый чек-лист вопросов для заказчика. Уже на основании этих ответов легче понять и заказчику, чего же он хочет на самом деле, и команде разработки, что от нее требуется. А потом настает черед задавать какие-то наводящие вопросы для уточнения или выявления требований.

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

Список вопросов для заказчика:

• Какова цель проекта? Какую проблему это решает? Какое business value оно несет?
• Это единственное возможное решение данной проблемы? Если нет, то какие еще есть варианты?
• Есть ли какие-то общие требования, проходящие сквозь весь проект? Например, если это интернет-магазин, то он должен полностью соответствовать законодательству, регулирующему онлайн-торговлю.
• Есть ли функциональные требования? Что должен делать раздел (страница, проект)? Например, раздел должен предоставлять информацию о продуктах компании и через форму на странице собирать желающих задать по этому продукту вопросы или приобрести его.
• Есть ли нефункциональные требования? Как хорошо он должен это делать? Например, время открытия страницы должно быть не больше 5 секунд.
• Дополнительные требования. Свободный формат, в котором можно излить душу.

Очередная проблема, с которой нам довелось столкнуться: задачи, поступающие одновременно со всех сторон. Когда много заказчиков по разным проектам, то каждый хочет выставить своей задаче наивысший приоритет. В общем идеальном случае, наверное, такую проблему нельзя решить на 100%. Как живем с этим мы? С внедрением дисциплины в постановке и ведении задач, а также некоторых элементов Agile-методологий, наш пул задач стал более упорядоченным, прозрачным для внешнего наблюдателя, а главное — прогнозируемым. Мы наладили порядок и планы у себя внутри команды, и нам осталось только усилить обратную связь с заказчиками. В обсуждении приоритетов, сроков и планов мы научились строить аргументированный диалог, а не слепо кидаться на задачи и постоянно тушить разгорающиеся пожары (которые на самом деле не всегда актуальны и не всегда пожары).

Также в рамках этого пункта мы постарались искоренить классический антипаттерн «чайка-менеджмент», когда заказчик или менеджер прилетел, «наложил» задач — и улетел в полной уверенности, что раз он задачу поставил, то непременно на выходе получится отличный результат. Как показала практика, результат при таком подходе получался не самый впечатляющий. Как с этим бороться? Тут тоже нет какого-то универсального совета, какой-то волшебной фразы, изменяющей поведение людей. Для этого необходимо разговаривать, просвещать, объяснять, показывать, можно сказать воспитывать. Только просветительская работа и либо очень наглядные, либо очень измеримые (а желательно и то, и другое) позитивные и негативные примеры помогут в достаточной мере побороть «чайка-менеджмент».

Dev vs Ops

И последняя важная наша проблема — проблема в коммуникациях между отделами Dev и Ops.
Мы столкнулись с классической ситуацией, когда разработчики не очень хорошо понимают, как работает сервер, а сторонняя команда админов не очень представляет, как работает приложение. Каждое затруднение на стыке этих двух сфер давалось нам с болью и большими временными затратами. Трудно было даже диагностировать, на какой стороне проблема:

• Это вы там напрограммировали!
• Нет, это у вас там что-то с сервером!

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

Разработка

Параллельно со всем эти мы занялись развитием культуры разработки.
Не буду заострять внимание на технической части, да и сейчас это уже стандарт де-факто и практически всем хватает понимания того, как необходимо наличие системы контроля версий, CI/CD и прочих инструментов разработки, сборки и деплоя. Остановлюсь лишь на soft моментах разработки.

• Codestyle. Довольно важно выработать и явно утвердить правила оформления кода. Во-первых, эстетически приятнее видеть в проекте единый стройный вид, а не зоопарк разных стилей и стандартов. Во-вторых, это повышает читаемость кода, а как мы знаем, большинство времени программист не пишет свой код, а читает чужой.
• Именование коммитов. Мы ввели определенные правила именования коммитов, чтобы по имени коммита было понятно, какие изменения были внесены, кем и в рамках какой задачи.
• Код-ревью. Специфика наших проектов и команды такова, что некоего обязательного код-ревью, без которого не влить свой код в продакшен, у нас нет. Однако мы взяли за правило, что хотя бы один человек смотрит тот код, который пушит коллега. Это помогает как замечать какие-то недочеты, привносить альтернативные идеи, так и просто быть в курсе всех частей системы. Код-ревью стало особенно актуальным с ростом количества и сложности проектов, из-за чего каждый разработчик уже не успевает поработать на всех проектах достаточно, чтобы понять все их детали.
• Согласование архитектуры внутри команды на ранних этапах. Часто бывает, что в стремлении создать фичу побыстрее, фронтенд начинает делать что-то свое, бэкенд быстро начинает свое, а потом оказывается, что это интегрируется с большим трудом или не интегрируется вообще. В разработке крупных фич мы заранее совместно обсуждаем архитектуру, форматы обмена данными и т. п. В результате интеграция перестала быть долгой и болезненной.
• CV Driven Development. Это проблема, при которой разработчики тащат в проект новые (свежие, модные, высокооплачиваемые) технологии не ради проекта, а ради галочки в резюме. Мы открыты для новых технологий и стараемся технологически развивать наши проекты, однако тут важно соблюсти баланс, при котором будет и технологический прогресс, и успешно выполненные в разумные сроки проекты. В этой скользкой теме важны две вещи: чтобы заказчик не давил сроками так, что разработчикам не продохнуть, и чтобы команду разработки (ну или, по крайней мере, компетентного тимлида или техлида) заботило не только развитие своего профиля в LinkedIn, но и благополучие проекта в целом.

Рефакторинг, технический долг и принцип непрерывного улучшения

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

Так как проект был большой, уровень энтропии был в нем также высок. Мы поняли, что за один присест это все не одолеть физически, да и морально опускаются руки от перспективы такой колоссальной работы. Мы решили применить японский принцип непрерывного улучшения «кайдзен». Раздробили технический долг на много маленьких частей и понемногу, но регулярно закрывали эти маленькие части, непрерывно модифицируя и улучшая как проекты, так и работу самой команды. Морально это никак не приносило неудобств, но при этом не оказывало значительного влияния на разработку новой функциональности и покрытие требований бизнеса. Спустя год-полтора мы обнаружили, что старый технический долг был полностью погашен, и это открыло нам возможности для разработки функциональности принципиально нового уровня сложности и важности.

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

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

Внедрение Agile-методологий

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

Первое, что мы сделали, — организовали ежедневные стендапы внутри команды. Так как команда распределенная, то в Slack отвели для этого отдельный канал, в котором каждое утро каждый сотрудник пишет три пункта: над какими задачами работал вчера, над какими планирует работать сегодня, есть ли какие-то проблемы, мешающие его работе. Флудить в этом канале, обсуждать чьи-то задачи или проблемы запрещено. Этот канал строго для агрегации информации о состоянии дел. Остальные обсуждения должны вестись в соответствующих тематических каналах. Это позволило каждому человеку в команде понимать, чем занимаются его коллеги, что происходит с проектом в общем, кому можно и нужно помочь. Если без стендапов проблемы замалчивались, а спустя долгое время неожиданно выяснялось, что задача еще не готова, то сейчас наглядно видно, кому требуется помощь, что нужно сделать, чтобы работа команды стала эффективнее.

Далее мы решили вести разработку по спринтам. Каждую пятницу в конце дня мы проводим ретроспективу спринта, смотрим, какие задачи были в планах, что готово, что не готово, и если что-то не готово, то почему так произошло. Думаем о том, какие у нас были проблемы и что мы могли бы сделать, чтобы избежать подобных трудностей в будущем. Затем планируем спринт на следующую неделю исходя из загруженности разных направлений внутри команды и бизнес-приоритетов. В результате в начале недели все разработчики знают, чем им заниматься и в какой последовательности, а бизнес знает, какие его потребности будут покрыты в ближайшее время, и может уже формировать свои «хотелки» на следующие спринты. Стоит сказать, что мы не избавлены от внезапных задач, которые могут нарушить наши планы на спринт. В этом случае нужно действовать исходя из конкретной специфики работы: как часто такие задачи возникают? Насколько много? Можно ли это спрогнозировать? В нашем конкретном случае в разработке мы опытным путем подсчитали, сколько времени в среднем приходится на незапланированные задачи и стараемся закладывать этот запас в спринт. Отдельно стоит отметить, что после начала работы по спринтам нам удалось конкретно выяснить, как много работы нам поставляется на вход внепланово, проанализировать и сократить это количество, тщательно обсуждая приоритеты с заказчиком и наглядно показывая, как сиюминутное желание получить не самую необходимую фичу прямо сейчас влияет на общую продуктивность всей команды.

Также мы перешли от длинных релизов к коротким. Раньше мы получали ТЗ, неделями или месяцами делали целый пак фич и только тогда показывали заказчику. В результате часто оказывалось, что заказчик либо передумал, либо ожидал не совсем того, и мы начинали переделывать все или часть того, что уже сделали. А вносить изменения в уже готовый большой набор фич — это сомнительное удовольствие. Сейчас мы демонстрируем каждую фичу как можно раньше, чтобы заказчик принял решение — то ли это, что он на самом деле хотел, или надо что-то изменить. Чем быстрее он либо утвердит, либо отправит на доработку, тем меньше трудозатрат мы вложим, следовательно, тем быстрее фича придет в продакшен. В результате фичи стали поступать в продакшен быстрее, быстрее проверяются гипотезы, быстрее пошло развитие проекта.

Bus factor

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

В искоренении этой проблемы нам помогло накопление артефактов знаний, которые переехали из голов конкретных людей в физический письменный мир. А именно:

• Все работы проводятся только если есть задача в багтрекере. Это позволяет составить полную историю изменений в проекте.
• В случае если где-то в чате или на митинге обсудили изменения по задаче — обязательно в самой задаче отражаем итог этого обсуждения.
• Коммиты именуются с понятным указанием произведенных изменений и ссылкой на задачу. При этом в багтрекере интеграция настроена так, что в самой задаче появляется ссылка на коммит в Gitlab. Это позволяет сохранить историю не только самой цели задачи и ее обсуждений, но и сохранить информацию о конкретных изменениях и их исполнителях.
• После разработки очередной фичи программист пишет в Confluence документацию, описывающую ее общую бизнес-логику и особенности реализации, если это необходимо.
• При возникновении каких-то крупных проблемных инцидентов ведется postmortem в формате «что и когда случилось — что делали — что нужно было на самом деле делать — как избежать такой проблемы в будущем».

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

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

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

Заключение

В заключение хотелось бы отметить, что ни одна из вышеуказанных проблем не решалась сразу и безупречно. Организационные изменения — это всегда долгий и методичный труд. Нельзя просто сказать «теперь делаем так» и надеяться, что теперь все станет иначе. Любые решения, которые вы примете, любые мероприятия, которые вы организуете, требуют контроля, обучения и просвещения людей, времени на адаптацию как команды к новым методикам, так и самих методик к конкретной ситуации. Также замечу, что навязывание людям какой-то методологии является очень трудоемким и малоэффективным процессом. Люди будут упираться, заб(ы/и)вать, возможно даже саботировать.

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

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

Автор: Евгений Антонов, руководитель группы разработки Positive Technologies

Термин «рабочий процесс» неоднозначен. Для одних рабочий процесс — это процесс как таковой, для других — способ организации информации.

Расплывчатость этого термина имеет реальные последствия. Отсутствие ясности в том, что такое рабочий процесс, вносить путаницу в саму работу, а это приводит к снижению её эффективности. Например, среднестатистический работник интеллектуального труда тратит 60% своего времени на работу по организации работы — поиск информации или отслеживание статуса работы. При этом каждую неделю срываются более четверти всех сроков выполнения работы. Несмотря на то, что мы упорно трудимся и заняты целый день, мы всё равно не успеваем и часто отстаём от графика.

Что-то здесь не так.

Именно здесь на помощь приходят рабочие процессы и понимание их сущности. Чётко зная, что такое рабочий процесс и как его реализовать, вы сможете эффективно организовать работу своей команды, достигать целей проектов и формировать эффективные карты процессов, которые будут служить вам долгое время. Узнайте, как это делается.

Что такое рабочий процесс?

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

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

Планирование:

1. Формирование идей и сбор информации

2. Приём запросов

3. Расстановка приоритетов и обеспечение ресурсами

Выполнение:

4. Проработка и анализ

5. Отслеживание хода выполнения

Анализ:

6. Согласование

7. Отчётность

Когда следует создавать рабочий процесс?

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

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

Знакомство с рабочими процессами в Asana

В чём заключается важность рабочих процессов?

Несмотря на то, что каждый рабочий процесс уникален, все они собираются из одних и тех же блоков, как в конструкторе «Лего». Эти основные компоненты обладают достаточной гибкостью, чтобы удовлетворить потребности любой команды или организации. Важнейшей частью является кодификация жизненно важных бизнес-процессов для создания структуры в рамках организации. Когда вы это сделаете, никто не будет задаваться вопросом, каким будет следующий шаг или кто управляет той или иной частью проекта. Устранение этой неопределённости имеет решающее значение.

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

• упрощение координации между участниками команды проекта;

• рост производительности (без дополнительных затрат и снижения качества);

• оптимизация распределения ресурсов;

• повышение прозрачности проектов;

• расширение возможностей руководителей для принятия более взвешенных решений, поскольку всё отслеживается в одном месте;

• уход от сбора информации вручную и дублирования работы;

• устранение разрозненности данных путём их группирования в централизованном источнике достоверной информации;

• чёткое представление о том, как работа отдельных сотрудников способствует реализации более глобальных целей и задач;

• уход от работы вслепую и высвобождение потенциала сотрудников;

• ликвидация спонтанных процессов и одноразовых систем путём их замены централизованным источником информации.

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

Три основных преимущества чётких рабочих процессов

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

Прозрачность в реальном времени

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

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

• получать практические сведения в режиме реального времени для повышения эффективности работы команды;

• точно планировать, выделять ресурсы, а также увеличивать или уменьшать объём работ по мере необходимости;

• информировать руководство и заинтересованных лиц из других подразделений о ходе проекта;

• сокращать задержки и добиваться более качественных результатов;

• получать общее представление о процессах в проекте, чтобы понимать, выявлять и диагностировать проблемы.

Согласованность действий внутри коллектива и между разными командами

Чётко сформулированные рабочие процессы обеспечивают ясность и необходимый контекст при взаимодействии нескольких разных команд. При наличии у вас сети связанных проектов или инструментов команды из разных подразделений чётко видят, как и почему выполняется та или иная работа.

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

Читайте о пяти способах устранения разрозненности в работе клиентов Asana

Повышение эффективности работы

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

Как рабочие процессы соотносятся с другими бизнес-процессами

При построении рабочего процесса в него обычно включаются различные бизнес-процессы. Вот как рабочие процессы отличаются от этих методов и соотносятся с ними:

Рабочие процессы и управление бизнес-процессами (BPM)

Бизнес-процесс — это последовательность задач. Управление бизнес-процессами (BPM) — это практика анализа и совершенствования бизнес-процессов эффективным и результативным способом.

Управление рабочими процессами осуществляется в рамках управления бизнес-процессами. Рабочие процессы позволяют организовать данные понятным и воспроизводимым способом, сосредоточившись на трёх ключевых действиях: планирование, исполнение и контроль. Эффективный рабочий процесс представляет собой воспроизводимый, устойчивый бизнес-процесс.

Читать: Руководство для начинающих по управлению бизнес-процессами (BPM)

Рабочие процессы и контрольные списки

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

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

Рабочие процессы и диаграммы Ганта

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

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

Читать о том, как начать пользоваться диаграммами Ганта

Рабочие процессы и блок-схемы

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

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

Читать о пяти этапах управления проектом для улучшения рабочего процесса команды

Рабочие процессы и управление работами

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

Примеры рабочих процессов

Прежде чем мы приступим к рассмотрению преимуществ определённых рабочих процессов и построению своих, давайте изучим несколько примеров таких процессов.

Рабочий процесс обратной связи с клиентами

1. Формирование идей и сбор информации: клиент отправляет тикет, запрос или отзыв.

2. Приём запросов: запрос обрабатывается в системе взаимодействия с клиентами, например в Zendesk.

3. Расстановка приоритетов и обеспечение ресурсами: запрос автоматически направляется в соответствующую группу. Например, если это запрос на продажу, он направляется в Salesforce для обработки отделом продаж. Кроме того, тикеты и отзывы передаются во внутренние группы, которые работают в таких инструментах управления работами, как Asana.

4. Проработка и анализ: группа работает над решением проблемы клиента.

5. Отслеживание хода выполнения: интеграции, работающие в режиме реального времени, оптимизируют и автоматизируют процессы, идущие между группами. Вместо того чтобы вручную рассылать оповещения или дублировать работу между инструментами, можно использовать такие интеграции, как Asana для Zendesk, чтобы обеспечивать своих сотрудников самой актуальной информацией на рабочем месте.

6. Согласование: окончательное решение доводится до отправителя через отдел по работе с клиентами. При необходимости изменения документируются. Если запрос не был удовлетворён в полной мере, группа возвращается к четвёртому шагу (проработка и анализ), чтобы ещё раз взглянуть на ситуацию.

7. Отчётность: данный конкретный запрос учитывается как часть общего рабочего процесса и влияет на оценку общего результата процесса обратной связи с клиентами.

Рабочий процесс управления кампаниями

1. Формирование идей и сбор информации: группа собирается в полном составе с целью коллективного обсуждения идей для новой кампании.

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

3. Расстановка приоритетов и обеспечение ресурсами: прежде чем определять приоритеты проектов и задач, руководитель проекта анализирует каждый элемент кампании, чтобы понять, как всё сочетается друг с другом. Затем он создаёт основной календарь кампании, чтобы все сотрудники получали представление о её ходе.

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

5. Отслеживание хода выполнения: пока его команда занята делом, руководитель проекта отслеживает прогресс с помощь платформы для управления работами. Если сотрудник сталкивается с проблемой или ожидаемые результаты задерживаются, руководитель может вмешаться и устранить препятствия.

6. Согласование: когда всё будет готово, руководитель проекта принимает работу. Кампания запускается.

7. Отчётность: независимо от результата кампании всегда есть чему поучиться. Руководитель проекта погружается в аналитику, опрашивает участников своей группы и выясняет, что получилось, а что можно улучшить.

Ознакомьтесь с рабочими процессами для управления кампаниями

Рабочий процесс планирования целей

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

2. Приём заявок: руководитель группы, её участники и главные заинтересованные лица проекта совместно работают над идеями предстоящих целей.

3. Расстановка приоритетов и обеспечение ресурсами: руководитель группы вырабатывает набор задач на следующий период. В идеале каждая задача должна способствовать достижению вышестоящей цели, создавая чёткость и согласованность.

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

5. Отслеживание хода выполнения: пока группа занята делом, её руководитель следит за ходом работы. Если прогресс замедляется или сроки срываются, он может вмешаться и устранить препятствия. И руководитель, и сотрудники регулярно публикуют обновления статуса через платформу для управления работой.

6. Согласование: сотрудники постепенно завершают работу. Менеджеры проверяют её, а затем принимают или запрашивают изменения при необходимости.

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

Семь шагов по созданию эффективного рабочего процесса

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

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

В приведённом ниже примере мы покажем, как создать рабочий процесс в Asana. Если вы не знаете, с чего начать, посмотрите, как программное обеспечение управления рабочими процессами своевременно предоставляет сотрудникам нужную им информацию, чтобы коллективы могли сосредоточиться на конечном результате.

Знакомство с рабочими процессами в Asana

Шаг 1. Формирование идей и сбор информации

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

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

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

Шаг 2. Приём запросов

Сформировав общее представление о том, над чем вы работаете, уточните детали и составьте план проекта. На данном этапе рабочего процесса не забудьте учесть все необходимые данные, информацию и потребности бизнеса. Это позволит обозначить процесс, который вы строите, заинтересованные стороны проекта, которые вы привлечёте, и работу, которую вы в конечном итоге выполните.

• Определите цели своего проекта и SMART-цели

• Создайте черновик устава проекта или преобразуйте имеющийся у вас устав в проектное задание

• Создайте план проекта, а также общую хронологию проекта, и поделитесь ими

• Определите главных заинтересованных лиц проекта с помощью матрицы RACI

• Назначьте организационное совещание по проекту

• Определите рамки проекта, чтобы предотвратить разрастание его объёма

• Укажите важные вехи проекта, а также его окончательные ожидаемые результаты

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

Продолжаем наш пример по рабочему процессу веб-разработки. Отталкиваясь от итогов проведённого коллективного обсуждения, вы готовите творческое задание. Используя такой инструмент управления работами, как Asana, вы переносите свои наработки из Miro в задание и объединяете их с другими сведениями о проекте, например с планом обмена информацией.

3. Расстановка приоритетов и обеспечение ресурсами

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

Эффективные рабочие процессы — это не только повышение производительности и выполнение как можно большего объёма работы, но и создание пространства для творчества. При успешной реализации управление загрузкой максимально повышает производительность сотрудников и устраняет путаницу, в результате чего вы с командой в конце каждого дня будете чувствовать себя удовлетворёнными, а не перегруженными.

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

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

Читать руководство по первым шагам в управлении ресурсами

4. Проработка и анализ

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

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

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

Продолжаем наш пример по рабочему процессу веб-разработки. После распределения работы ваши дизайнеры создают в Figma макет новой домашней страницы сайта, который затем прикрепляют к проекту. С помощью функции «Корректировка» заинтересованные лица комментируют PDF-файлы, оставляя конкретные отзывы о том, что работает, а что нет. После того как заинтересованные лица проекта одобрят дизайн, его можно будет передать команде веб-разработчиков, не дублируя работу. Вместо этого всё необходимое хранится в проекте запроса на творческие работы и в проекте веб-производства, поэтому все работают на основе самой актуальной информации.

5. Отслеживание хода выполнения

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

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

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

Читать полное руководство о выборе универсального инструмента составления отчётности для руководителей команд

6. Согласование

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

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

7. Отчётность

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

Завершаем наш пример. Ваша домашняя страница запущена — поздравляем! Последний шаг — следить за тем, как она работает, и сообщать о её развитии. В следующий раз, когда вам понадобится запустить веб-страницу, воспользуйтесь полученными в ходе этого проекта знаниями, чтобы сделать свою работу ещё лучше.

Выстраивание совместных цифровых процессов

Как сказал Ральф Уолдо Эмерсон: «Жизнь — это путешествие, а не пункт назначения». То же самое справедливо и в отношении рабочих процессов. Сосредоточив внимание на процессе работы и улучшив его, вы сможете снабдить сотрудников инструментами и информацией, необходимыми для достижения успеха.

Знакомство с рабочими процессами в Asana

Методы организации работ (последовательный, параллельный, поточный)

БЛОК ОРГАНИЗАЦИЯ СТРОИТЕЛЬНОГО ПРОИЗВОДСТВА

Методы организации работ (последовательный, параллельный, поточный).

Различаются три метода организации производства работ: последовательный, параллельный и поточный.

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

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

Последовательный метод – предполагает последовательное выполнение отдельных видов работ на всем объекте. Применим при небольших объектах.

Достоинства: — требует минимума ресурсов; — выполнение техники безопасности; Недостатки: — максимальная продолжительность.

Параллельный метод – объект разбивается на фронты. Может быть применен при больших в плане объектах. Метод использует совмещение однотипных работ.

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

Поточный метод организации работ – совмещение разнотипных работ. При прочих равных условиях работы необходимо организовать поточным методом.

Источник

Последовательный метод организации строительных работ

Воскресенский Д., Дементьева А., Медведев П., Панин А., Панкратов Е., Сазонова А., Титова М., Щигорцова А.

При последовательном методе организации строительства создаются комплексные бригады, работники которых выполняют работы вначале на первом объекте, а после их полного завершения переходят на следу­ющий и далее на остальные.
Продолжительность сооружения объектов Т будет максимальной, складываемой из сроков сооружения всех объектов t, потребность же в людских ресурсах — минимальной. Каждый из видов ресурсов в процессе строительства будет использоваться периодически; на каждом этапе строительства требуются ра­бочие разной специальности, разные машины и материалы. Частично это можно сгладить, используя рабочих, владеющих несколькими специальностями, применяя универсальные машины, пригодные, напри­мер, для выполнения работ по строительству фундаментов и монтажу стен зданий. При таком методе организации необходимы построение и четкое соблюдение графиков поставки машин и материалов, движения рабочей силы.
Достоинства метода:
— простота его организации;
— низкая чувствительность к изменению и даже отказу от ритмичности работ;
— высокая степень альтернативности цепи (последовательности работ), так как её характер может быть достаточно свободно изменён в любой момент времени;
— общее количество рабочих, занятых на строительстве объекта постоянно и имеет минимально возможное значение.
Недостатки метода:
— большая продолжительность выполнения комплекса работ — максимальная по сравнению с другими методами при равной интенсивности работ;
— неизбежные простои машин, бригад, определенные трудности у заводов-изготовителей, транспортных и снабженческих организаций, обусловленные частой сменой видов материалов и конструкций.

Работа выполнена совместно студентами группы ИГЭС — 5 — 11 Титовой М. manysha-titova@yandex.ru Дементьевой А. nikol94@bk.ru Сазоновой А. sazonchik93@mail.ru и группы ИГЭС — 5 — 10 Медведевым П. stoked93@mail.ru Воскресенским Д. d_voskresensky@mail.ru Панкратовым Е. pankratov1evgeniy@gmail.com Паниным А. paninaleksey1@yandex.ru Щигорцовой А. alexan-0@mail.ru

Автор публикации

maria_titova_iges_5_11

Оставьте комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

Последовательный метод организации работ

Последовательные методы организации работ применяются с тех пор, как существует труд.

Они характеризуются с одной стороны последовательностью выполнения работ комплекса, а с другой — отсутствием одновременности их выполнения.

Необходимость их применения определяется:

· конструктивными особенностями сооружений;

· простота его организации;

· низкая чувствительность к изменению и даже отказу от ритмичности работ;

· высокая степень альтернативности цепи (последовательности работ), так как её характер может быть достаточно свободно изменён в любой момент времени (рис.3.).

· Большая продолжительность выполнения комплекса работ — максимальная по сравнению с другими методами при равной интенсивности работ;

· Большая потребность в ресурсах — максимальная по сравнению с другими методами при одном и том же сроке выполнения комплекса работ.

В следствии указанных недостатков последовательные методы организации работ в качестве самостоятельных применяются весьма редко, за исключением случаев, когда эти методы единственно возможны (трубы, мачты, башни, градирни, и др.). Однако последовательные методы имеют место во всех методах.

Продолжительность выполнения комплекса работ при последовательном методе равна сумме продолжительности всех работ комплекса, т. е.:

.

Рассмотрим два варианта выполнения комплекса при одних и тех же исходных данных (рис. 1).

Рис. 1 Исходные данные

Календарный план (циклограмма) производства работ последовательным методом по принципу неразрывности работ (ресурсов) (Рис. 2.).

Рис. 2. Календарный план (циклограмма) производства работ последовательным методом в соответствии с принципом неразрывности работ.

Рис.3. Календарный план (циклограмма) производства работ последовательным методом в соответствии с принципом неразрывности работ на частных фронтах (захватках).

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

Оптимизация последовательных методов организации работ в зависимости от принимаемого критерия заключается:

· В выборе рациональной интенсивности работ, обеспечивающей выполнение комплекса работ в директивный срок;

· В выборе метода, обеспечивающего непрерывное использование ресурсов или непрерывное освоение фронтов (захваток) работ;

· В выборе метода, предполагающего изменение интенсивности в процессе производства работ

Источник

Последовательный метод организации работ

— применяется при строительстве небольших объектов. Заключается в том, что на объекте в каждый момент времени выполняется один вид работ, по окончании которого начинается другой вид работ.

А — Земляные работы;

Рис.8. Пример 2. Последовательный МОР

2) хорошие условия для соблюдения техники безопасности;

3) требуется минимальный расход ресурсов.

«–»: максимальная продолжительность работ.

Параллельный метод организации работ

— это такой метод, при котором в одно и то же время на разных фронтах выполняются работы только одного вида.

Для организации этого метода объект разобьем на фронты.

Рис.9. Виды фронтов

Однотипные работы выполняем одновременно. Арабскими цифрами обозначим номера бригад, механизмов.

Рис.10. Пример 3. Параллельный МОР

Характеризуется совмещением однотипных работ.

«+»: минимальная продолжительность работ.

«–»: 1) максимальный расход ресурсов;

2) ухудшаются условия для соблюдения техники безопасности.

Поточный метод организации работ

Рис.11. Пример 4. Поточный МОР

Характеризуется совмещением разнотипных работ.

Внимание: Общее параллельного и поточного методов организации работ: есть совмещение!

«+»: при минимуме ресурсов сократили продолжительность, доведя ее до приемлемых сроков.

В поточном методе использованы достоинства последовательного МОР (минимум ресурсов), а сокращение сроков строительства достигается совмещением разнотипных работ.

Формы календарных планов

Внимание: Разбивка на фронты производится, чтобы работы разбить на поточный и последовательный МОР (по технике безопасности)!

Календарные планы могут быть представлены в виде:

1. Линейного графика;

3. Сетевого графика.

(США, Г.Л. Гант, 1895 г)

Рис.12. Пример линейного графика

В характеристику работ входят:

б) единицы измерения;

г) затраты труда в чел.-дн;

д) состав бригады (количественный и квалификационный);

е) механизмы, требуемые при производстве работ;

ж) затраты машинного времени;

з) число смен в сутках;

и) продолжительность выполнения работ.

3) под графиком в том же масштабе времени можно построить график движения рабочих.

«–»: 1) видно время выполнения работы, но не указано место выполнения работы;

2) нечетко показаны связи между работами, т.е. не видно из графика, все ли условия поточной организации работ выполнены.

Циклограмма Будникова

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

Календарный план представляется в двух координатах: по горизонтали – календарное время, по вертикали – фронты работ.

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

Рис.13 Пример циклограммы

«+»: 1) позволяет проследить, все ли условия поточной организации работ соблюдаются;

2) так же как и в линейном графике можно показать график движения рабочих в том же масштабе времени.

«–»: сложность его выполнения.

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Источник

Последовательный способ организации работ

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

Поточный метод совмещает и устраняет недостатки последовательного и параллельного методов организации строительного производства, одновременно сохраняя преимущества каждого из них. При этом методе технологический процесс возведения зданий и сооружений расчленяется на определенное количество составляющих процессов (устройство фундаментов, возведение стен, перекрытий и крыши, производство отделочных работ и др.). Для каждого процесса определяют одинаковые сроки производства работ и осуществляют совмещение их выполнения по времени в различных зданиях. При поточном методе работы по возведению каждого из домов делят на п процессов, на выполнение которых отводится одинаковое время. На комплексе из N домов однородные процессы выполняются последовательно друг за другом, а разнородные — параллельно. Для такого метода необходимо меньше времени на строительство нескольких зданий, чем при последовательном методе его организации. В то же время требуется меньшее количество одновременно потребляемых ресурсов по сравнению с параллельным методом организации строительного производства. При этом продолжительность строительства N зданий, расчлененных на п процессов, определяется по формуле (рис. 5) [c.45]

Последовательный метод организации строительства заключается в том, что каждый последующий строительный процесс выполняется после завершения всех работ по предыдущему процессу. Модели при последовательном методе ведения работ в рассматриваемом примере представлены на рис. 5. График движения трудовых ресурсов при этом методе организации работ приведен на рис. 6. [c.35]

Последовательный метод организации работ наиболее эффективен при строительстве разнотипных объектов с различными технологией и объемами работ. Объекты, как правило, группируются по принципу однородности объемно-планировочных и конструктивных решений. В пределах этих групп объектов работу бригад организуют последовательно. Затем производится увязка этих отдельных групп в общий поток. Наиболее широкое распространение такая организация работ бригад нашла при весьма узкой технологической специализации строительных организаций. [c.42]

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

ОРГАНИЗАЦИЯ СТРОИТЕЛЬНОГО ПРОИЗВОДСТВА — система мероприятий, обеспечивающих осуществление произ-ва строит.-монтажных работ наиболее рациональными методами и в наиболее рациональной последовательности в целях сокращения продолжительности строительства, снижения трудоемкости, себестоимости и улучшения качества строит.-монтажных работ. [c.125]

Требование планирования и осуществления строительства в строгом соответствии с установленными нормами продолжительности предопределяет порядок разработки производственной программы строительных организаций исходя из конечных результатов строительного производства. Отсюда необходимость последовательного применения балансовых и нормативных методов планирования в их сочетании и взаимодействии. [c.339]

Технология сооружения объекта отражает принципиальные особенности применяемых методов производства и организации всего комплекса строительно-монтажных работ. В понятие технологии производства какого-либо вида работ включается не только содержание И последовательность выполнения производственного процесса, но и возможность совмещения во времени отдельных работ или операций. Основные правила производства строительно-монтажных работ определены СНиП и отраслевыми инструкциями и рекомендациями. [c.74]

Строительство линейной части магистральных трубопроводов выполняют поточным методом с помощью специализированных или комплексных механизированных колонн, обеспечивающих последовательное взаимосвязанное и непрерывное выполнение всех линейных строительно-монтажных работ с единым темпом продвижения их по трассе и с разрывами между ними, обусловливаемыми технологией и организацией производства отдельных видов работ. [c.38]

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

Одним из важных условий организации учета затрат на производство по нормативному методу в строительстве является применение технологических карт (правил) или другой технической документации, в которой регламентирована наиболее экономичная и целесообразная в конкретных условиях стройки технология строительного производства, определена, исходя из действующих норм, потребность в трудовых затратах и материальных ресурсах. Применение технологических карт (правил) дает возможность персоналу строек вести работу по твердому технологическому режиму, заранее определять методы и последовательность выполнения отдельных работ, состав бригад рабочих и другие показатели, осуществлять выписку первичной документации отдельно на работы, предусмотренные технологией, и отдельно на работы, не предусмотренные технологией. [c.337]

Современные методы организации срциалистического строительного производства подразделяются на последовательные, параллельные и поточные. [c.41]

В нашей стране по решению правительства СССР запрещено капитальное строительство без утвержденных проектов и смет. Последние должны быть экономичными и отражать передовой отечественный и зарубежный опыт. В решениях XXVII съезда КПСС отмечается, что необходимо применение экономичных объемно-планировочных решений, конструкций, материалов, передовых методов организации производства и труда, последовательно сокращая расход материальных, топливно-энергетических и трудовых ресурсов на единицу продукции. Осуществить на этой основе снижение в проектах строек двенадцатой пятилетки удельных показателей сметной стоимости строительства, в том числе строительно-монтажных работ в среднем по народному хозяйству на 4—5 % [3, с. 310]. [c.189]

П. п. р. содержит календарный план произ-ва работ, устанавливающий последовательность и сроки выполнения всех строительно-монтажных работ график поступления строительных конструкций, деталей, полуфабрикатов, технологич. оборудования и основных материалов и комплектовочную ведомость (для первого года строительства — по месяцам, для последующих лет — по кварталам) график движения рабочих по профессиям график работы основных строительных машин строительный генеральный план с указанием расположения постоянных и временных транспортных путей, кранов, механизированных установок, складов, схем энерго-, водо-, теплоснабжения и других сооружений и устройств, необходимых для нужд строительства. В П. п. р. для объектов жилищно-гражданского строительства даются также схемы раскладки деталей и основных материалов. При необходимости строительные генеральные планы составляются для различных периодов строительства, напр, при строительстве крупного здания — на период возведения его подземной и отдельно — надземной частей. В составе П. п. р. разрабатываются технологич. карты на сложные работы и работы, выполняемые новыми методами, не получившими широкого распространения. На остальные виды основных строительно-монтажных и специальных работ составляются схемы организаций работ и описания последовательности и методов произ-ва работ с подсчетом необходимых затрат труда и материалов. Р П. п. р. для объектов жилищно-граждан-ского строительства составляются технологич. карты на земляные работы, монтаж фундаментов, стен, перекрытий, крупнопанельных перегородок, блоков и панелей с санитарно-технич. и электротехнич. устройствами, карниза и крыши. В технологич. картах даются схемы организации строительных, монтажных и спец. работ основные указания о последовательности, методах произ-ва работ и организации труда график выполнения работ потребность в основных материаль-но-технич. ресурсах и приспособлениях калькуляции затрат труда. В них предусматривается также применение наиболее прогрессивной технологии строительного произ-ва. В составе П. п. р. разрабатываются рабочие чертежи временных зданий и сооружений, а также различных устройств и приспособлений (при отсутствии типовых решений) решения по технике безопасности, требующие проектной разработки (укрепление земляных выемок, временное крепление монтируемых конструкций, устройство ограждений, лесов и т. п.). Краткая пояснительная записка к П. п. р. содержит необходимые обоснования принятых решений с приведением следующих технико-экономич. показателей продолжительность строительства, уровень применения сборных конструкций, уровень механизации основных строительно-монтажных работ, [c.320]

На основании проекта организации строительства разрабатывается проект производства работ для предприятий, их отдельных очередей, пусковых комплексов, зданий и сооружений. В состав проекта производства входят следующие документы календарный план производства работ или комплексный укрупненный сетевой график стройгенплан график поставок на объект строительных конструкций, изделий, полуфабрикатов, материалов и оборудования и комплектовочных ведомостей на них график потребности в рабочих кадрах и основных строительных машинах технологические карты на сложные и выполняемые новыми методами работы типовые технологические карты для остальных работ, привязанные к объекту и местным условиям строительства техноло гические схемы последовательности и методов производства работ технологические схемы на производство геодезическо-маркшейдерских работ. Кроме этих документов, в ППР даются решения по охране труда и технике безопасности, план работ по охране окружающей среды, документы по осуществлению контроля и оценки качества строительно-монтажных и специальных работ, пояснительная записка с технико-экономическим обоснованием производства строительных работ. [c.41]

Впервые в отечественной практике поточный метод был применен в 1949 г. на строительстве газопровода Дашава—Киев— Брянск—Москва. В 1953г. были утверждены Временные технологические правила (инструкция) производства работ при строительстве линейной части магистральных стальных трубопроводов , в которых в качестве важнейшего условия выполнения строительных работ в сжатые сроки выдвигалась организация поточного выполнения в определенной технологической последовательности всех видов строительных и монтажно-сварочных работ одновременно на всех линейных участках трассы . [c.48]

В новой системе ценообразования индексы применяются к базисной сметной стоимости 2000 года, определенной по единичным расценкам или по элементным нормам ресурсным методом с учетом базисной стоимости ресурсов. Как правило, индексы формируются на строительные, ремонтно-строительные, монтажные, пус-коналадочные, иногда и на реставрационно-восстановительные работы, предусмотренные наиболее распространенными проектными решениями частей зданий и сооружений и дифференцированы по унифицированной номенклатуре видов и комплексов работ, соответствующих технологической последовательности строительства и специализации строительно-монтажных (ремонтно-строительных, реставрационных) организаций. [c.273]

Значение материала модели. Случайный, необоснованный г.ыбор материала может не только сдерживать развитие и практическое применение нового метода или ограничить его возможности, но и принципиально исказить его сущность. Вот один из наиболее ярких примеров этого, ставший уже нарицательным в истории макетно-модельного проектирования. В ленинградском институте Ленгипрогаз — первой в нашей стране организации, применившей макеты при проектировании объектов нефтехимических производств, — было найдено в общем правильное понимание роли макета в проектировании и строительстве. Макет был принят как средство проектирования, и он же направлялся на строительную площадку для применения в качестве проектной документации при монтаже трубопроводной части объекта. Учитывая возможные жесткие для конструкции макета условия транспортирования и эксплуатации на месте строительства, было также последовательно правильно оценено значение его прочности карг изделия. И тем не менее была допущена серьезная ошибка — чрезмерное увлечение прочностью в ущерб прочим требуемым качествам моделей. Макет стал в буквальном смысле железным почти все его элементы выполнялись из металла. В процессе сборки модели соединялись между собой на пайке.. Естественно, что ни о какой разъемности соединений и [c.204]

Основные части проекта предприятия — технологическая, строительная и технико-экономическая. Тех-нологич. часть проекта содержит решения по организации произ-ва, технология, процессу и по выбору оборудования, определяющие мощность предприятия, а также методы механизации и автоматизации произ-ва. Строительная часть определяет характер и тип зданий и сооружений, их объемно-планировочные и конструктивные решения часть проекта Организация строительства устанавливает объем строительно-монтажных работ по каждому объекту, последовательность и сроки строительства и методы произ-ва основных работ, а также выявляет потребность в основных строительных материалах и деталях, строительных машинах, транспортных средствах и рабочих кадрах. В технико-экономич. части обосновывается выбор места строительства, устанавливаются основные технико-экономич. показатели проектируемого предприятия, характеризующие экономич. эффективность принятых проектных решений. Неотъемлемой частью проекта является смета затрат, в к-рой устанавливается стоимость строительства. Проектно-сметная документация служит основой для организации планирования и финансирования строительства, а также для расчетов за выполненные работы. [c.322]

Источник

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

Систематизация рабочих процессов

Эффективный рабочий процесс – это, в первую очередь, понятный рабочий процесс. Во вторую – процесс, который закрывает все потребности предприятия.

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

Это пример непоследовательного, “поломанного” рабочего процесса, который выливается в финансовые потери.

Когда бизнес утыкается в “потолок” из-за неэффективности, опозданий, сорванных дедлайнов – это повод задуматься о систематизации процессов. И здесь вопрос стоит не только о всей компании, здесь важно наладить работу каждого отдельного сотрудника. Потому как люди – это “винтики” механизма любого бизнеса.

Систематизация рабочих процессов – это последовательное описание порядка действий по отдельности и в совокупности, которое в итоге позволяет видеть работу компании как на ладони. Главные цели систематизации:

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

Систематизация рабочих процессов – это база для будущей автоматизации. Если в процессах бардак, то с автоматизацией получится “очень быстро происходящий бардак”. И важно начинать с себя – с внутренних рабочих процессов.

Этапы автоматизации управления бизнес-процессами

Автоматизировать – значит сделать быстрее, удобнее, сократить расходы, исключить ошибки и поправку на человеческий фактор, нивелировать разобщенность работы отделов и подразделений.

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

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

В целом автоматизация управления бизнес-процессами проходит 4 основных этапа:

1. Моделирование.

   Здесь важно определить логику процесса, “нарисовать” поэтапное развитие и указать ответственных за каждый этап. Немаловажно, чтобы каждый шаг имел смысл. Если смысла нет, то это – лишний шаг, который усложняет исполнение процесса, делает его более дорогостоящим в части финансов и затрат времени.

2. Отладка.

   Это этап тестирования. Когда бизнес-процесс смоделирован, его проверяют на “жизнеспособность”. Это позволяет быстро исправить ошибки, если они вдруг выявляются.

3. Исполнение.

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

4. Контроль.

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

Причины неэффективной реорганизации БП

Как показывает практика, усовершенствованные рабочие процессы внутри компании или предприятия дают позитивные изменения бизнесу в целом. Уже за год повышаются:

• точность планирования – на 40%;
• эффективность производства – на 50%;
• скорость принятия верных управленческих решений – на 80%.

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

• “ошибка выбора”. Руководители зачастую фокусируются на частностях, из-за чего выбирают для автоматизации не самый ключевой рабочий процесс;
• “всё и сразу”. Хвататься сразу за все бизнес-процессы – одна из самых частых причин низкой результативности автоматизации. В первую очередь нужно концентрировать усилия на самых неэффективных процессах;
• “с чистого листа”. Зачастую управленцы рубят с плеча, думают, что гораздо проще создать новый процесс, чем заниматься усовершенствованием старого. Подвох состоит в том, что важная для исключения ошибок информация “зарыта” как раз в уже существующем процессе. Поэтому забыть про них – как выбросить ключ к ответам и повышению эффективности безвозвратно в море. Гарантии, что новый процесс будет безошибочным и идеальным, нет;
• “не помним цели”. Процесс совершенствования бизнес-процессов настолько увлекателен, что бывает, руководители забывают о цели автоматизации – сделать удобнее и проще – и нагромождают процессы лишними звеньями;
• “сделать и забыть”. Даже когда все сделано верно, есть риск не увидеть повышения эффективности, если не отслеживать, как выполняется бизнес-процесс. Прописать идеальную картинку – это одно; контролировать, чтобы она соответствовала действительности – другое. Здесь помогут решения для мониторинга работы персонала.

Автоматизация учета рабочего времени

Автоматизация учета рабочего времени персонала – это основа успешного предприятия. Такой подход позволяет:

• наладить работу внутри компании: сократить операционное трение, сделать взаимодействие отделов и подразделений эффективным;
• создать прозрачную структуру исполнения бизнес-процессов: увидеть, где образовываются “точки слома”, кто оказывается “слабым звеном” в рабочей цепи;
• контролировать исполнение эффективных моделей процессов.

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

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

Онлайн-фотография рабочего дня

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

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

Метод фотографии рабочего дня можно реализовывать несколькими способами:

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

Выгоды автоматического способа очевидны: во-первых, персоналу не нужно тратить время на составление дополнительных отчетностей о своей работе; во-вторых, руководителю не нужно расходовать свои часы на анализ бумажных или электронных таблиц с информацией о работе подчиненных. Готовая аналитика – первое, за что отдают предпочтение именно автоматизированным системам. Например, на основе данных, собранных в рамках функции “фотография рабочего дня” программы CrocoTime, можно сразу увидеть:

• как долго сотрудник выполнял ту или иную задачу. Это может служить поводом рассмотреть рабочий процесс детально и выяснить, в чем причина задержки в исполнении. Это может быть недостаточная квалификация или же “дефект” самого процесса;
• сколько времени тратится непосредственно на работу (совещания, переговоры и т.д.), а сколько – на отвлечения, перекуры, незапланированные перерывы;
• какими ресурсами пользуется подчиненный – профильными или нет. При этом важно отметить, что о шпионаже речь, по крайней мере, в CrocoTime, не идет: все, что делает программа – это фиксирует заголовки открытых окон;
• кто из коллектива перерабатывает, испытывает повышенную нагрузку, а кто – с успехом прокрастинирует или перекладывает свои обязанности на плечи коллег.

Вся эта информация служит источником для принятия решений по оптимизации рабочих процессов.

Повышение эффективности рабочих процессов

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

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

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

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

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

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

Хаотичная или последовательная организация работы команды