Выбрать страницу

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

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

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

Таким образом, то, о чем довольно давно говорили эксперты, а именно, что качество ИТ определяется не только функциональностью ПО, но и многими другими характеристиками, стало очевидно многим. Хотя еще в 2015 году подход к качеству ПО был значительно расширен и появились первые стандарты серии SQUARE (Systems and software Quality Requirements and Evaluation — Требования и оценка качества систем и программного обеспечения, стандарты ГОСТ Р ИСО/МЭК 250**, например, ИСО/МЭК 25010-2015 Модели качества систем и программных продуктов). Хочется также отметить, что современные ИТ позволяют не только в подавляющем большинстве случаев достичь требуемых значений параметров качества, но и мониторить их изменения в оперативном режиме. Почему этому не уделяется достаточно внимания? Обычно в ответ на вопросы такого рода я слышу: «Не хватает бюджета», несколько реже: «Не успеваем, на это нет времени».

Бюджет

Как член проектных команд, руководитель и куратор множества проектов могу сделать вывод, что качество разрабатываемого ПО никоим образом не зависит прямо пропорционально от бюджета, выделенного на проект. Скорей даже наоборот. Дорогостоящие проекты, к которым есть повышенное внимание и над которыми осуществляется строгий контроль, редко бывают успешными. Проектная команда и РП таких проектов слишком боятся совершить ошибку, что не идет на пользу делу. Излишняя осторожность приводит к топтанию на месте, а основные силы уходят на то, чтобы доказать руководству, что деньги потрачены не зря. В ход идут и потемкинские деревни, и цветастые презентации, и развернутые дэшборды. А поскольку силы проектной команды не безграничны, то собственно на создание результата проекта их уже не остается. В нашей книге по цифровой трансформации[1]
есть глава, посвященная бюджетированию. Там речь идет о проектах цифровой трансформации, но описанные методы вполне подходят и для проектов автоматизации. Давно пора прекратить годовое бюджетирование, которое является пережитком советской эпохи и государственного централизованного планирования. В книге Терри Райт убедительно доказывает, что такой подход идет вразрез с методиками гибкой разработки ПО. Собственно годовое бюджетирование зачастую является основным препятствием внедрения таких методик в деятельность организаций. Конечно, планирование на столь серьезный срок препятствует гибкости, необходимой в современных условиях проектам ИТ, даже если они ведутся по каскадной модели. Мало того, такое планирование препятствует динамичности организаций, которая им необходима и в других областях деятельности. Бюджет надо планировать на короткие сроки, каждый раз анализируя, стоит ли продолжать проект, по-прежнему ли он соответствует потребностям компании. Если такое планирование идет вразрез с финансовой политикой компании (и эта политика «священна»), то целесообразно бюджетировать портфель проектов, внутри которого использовать более гибкие методы распределения бюджета. В заключение хочу отметить, что все мегадорогостоящие ИТ-проекты, про которые я знаю и которых немало, окончились громкими провалами.

Сроки

В очередной раз не могу отказать себе в удовольствии привести цитату С. П. Королева: «Имейте в виду, если вы сделаете быстро и плохо, то люди забудут, что вы сделали быстро, и запомнят, что вы сделали плохо. Если вы сделаете медленно и хорошо, то люди забудут, что вы сделали медленно, и запомнят, что вы сделали хорошо!» По собственному опыту знаю, что во многих случаях гонка при выполнении проектов ничем не обоснована. РП, вооруженный знанием проектного управления по версиям РМВОК (до 7-й версии) и не всегда обладающий достаточными компетенциями в содержании ИТ-проекта, зачастую связанного со сложными современными технологиями, управляет тем, чем проще управлять или тем, чем он может управлять, — сроками и бюджетом. Проблема ИТ-проектов заключается в их двойной сложности: и с точки зрения технологий, и с точки зрения управления проектом. В реальности редко встречаются руководители, готовые возглавить и создание результата, и процессы управления проектами. Еще до появления и тем более массового распространения Agile-методик на сложных, грамотно управляемых проектах, я сталкивалась с «двухголовым» управлением: один из руководителей (Team Leader, архитектор проекта, Product Manager и т. д.) и РП. Мой опыт такого управления вполне положителен. Одна из гибких методологий разработки ПО — «Скрам» узаконила такой подход. Там есть Product Owner, отвечающий за содержание и результат проекта, и Scrum Muster, регулирующий ресурсы и организующий эффективное использование методологии, в частности проведение необходимых встреч и митингов. «Скрам» используется уже более 20 лет в проектах разного масштаба, сложности и длительности. То есть такое деление вполне оправдано.

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

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

Поддержка и эксплуатация

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

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

На удивление, люди, понимающие, что ситуация нестандартная, все еще цепляются за неэффективные и устаревшие методы как за спасительный якорь, за точку опоры в стремительно меняющемся мире. Но еще Джек Уэлч, генеральный директор General Electric, отмечал: «Если скорость изменения снаружи превышает скорость изменения внутри, конец близок». В современных условиях это высказывание звучит устрашающе. Но смысл его, тем не менее, подтверждается реальными событиями.

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

Тут следует вспомнить о тренингах, которые и в «мирное время» рекомендовались для первой линии поддержки. Поскольку это именно те люди, которые принимают на себя основной негатив по поводу неработающих ИТ-сервисов. Рекомендовались то рекомендовались, но крайне мало кто уделял этому внимание. А потому текучка в службах сервис-деск всегда остается высокой. Когда-то, помню, встречала статистику, что средний срок работы на первой линии поддержки составляет пять месяцев. После этого человек «выгорает», и ему нужно восстанавливаться.

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

Психологические аспекты

Некоторые сотрудники жалуются на то, что дома работать невозможно: с одной стороны, физически мешают родственники, с другой — психологически трудно собраться. Но и в офисе, особенно в модных open space, есть кому мешать. Смею утверждать, что в большинстве случаев найти общий язык с домочадцами все же проще, чем с рабочим коллективом. Как говорят психологи, надо освоить установление личных границ, и тогда все получится. Что касается психологических аспектов, то современный человек все же должен становиться хозяином своей жизни. А не ждать, пока придет надсмотрщик с кнутом и начнет его погонять. И если работа интересна, то работник не будет до полудня валяться на диване.

Другой аспект — прямо противоположный, на который жалуются работники, выведенные на удаленную работу, — это то, что границы между работой и всей остальной жизнью размываются. Что приводит к необходимости постоянно переключаться с одного дела на другое и ведет к хронической усталости. Забавно, что подобные вопросы по поводу, как разделять работу и остальную жизнь, я слышала задолго до пандемии. Об этом спрашивали студенты, с которыми мы обсуждали мобильные технологии. Им я отвечала, что все зависит о того, как правильно построить работу. Если деятельность, за которую ты отвечаешь, хорошо налажена, то, уехав, например, в отпуск, ты со спокойной душой можешь оставить ее на заместителя. Но в любой работе бывают нештатные ситуации. И тогда лучшее, чтобы ты об этом знал, где бы ни находился. Опять же, такая доступность в любое время и из любого места требует пересмотра некоторых привычек, другого подхода к тому, как организовывать свое время. Но это связано вовсе не с пандемией, а развитием средств связи. Так что учиться все равно бы пришлось. Может быть, не в такие короткие сроки и не в таком объеме.

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

Особенности управления

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

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

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

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

[1]
«Цифровая трансформация бизнеса» Аншина М., Славин Б., Райт Т., «КноРус», 2021