Мой доклад будет о практическом применении гибких подходов в управлении командой проекта при автоматизации бизнес-процессов для крупных компаний. Я поделюсь кейсами, которые использовал на проекте, чтобы добиться успеха.
Меня зовут Александр Рыжов. Я директор и руководитель проектов компании ИТАН. Специализируюсь на повышении эффективности систем финансового управления на платформе 1С.
Прошел путь от консультанта-эксперта до руководителя проектов и директора компании. Лично внедрил более 50-ти разнообразных проектов. Также являюсь преподавателем ряда московских вузов.
Компания ИТАН специализируется на автоматизации финансового управления, финансового блока и бизнес-процессов.
Компания работает с 2001 года. Последние пять лет мы активно применяем гибкие методики, потому что они очень помогают достигать поставленного результата и добиваться бизнес-целей для заказчика.
Так сложилось, что, как правило, к нам приходят заказчики с изысканными или неординарными задачами, когда их по разным причинам не устраивают другие решения на платформе 1С. Об одном из таких проектов и пойдет речь.
В этом докладе я расскажу:
-
про цели и задачи нашей команды на примере ведения проекта в компании «Текта групп»;
-
как применялись практические инструменты гибкого управления командами;
-
о технологических и организационных приемах, чтобы эффективно вести проекты.
Подробнее о проекте
Компания «Текта групп» – это холдинг, специализирующийся на строительстве жилых комплексов от котлована до квартиры «под ключ». За время своего существования компания построила более миллиона квадратных метров недвижимости. Входит в топ-10 крупнейших корпораций Москвы по объему строительства.
Заказчик переходил с Navision на платформу 1С. В качестве базового решения было выбрано 1С:ERP с дополнительными модулями:
-
Управление строительной организацией
-
«ИТАН:Управленческий баланс»
-
«Табула» для бюджетирования
Как вы понимаете, получился достаточно большой монстр: единая база данных. Только в основном интерфейсе было 27 разделов меню – это достаточно много.
«Текта» поставила перед нами задачи автоматизировать:
-
управленческий учет, финансовую и аналитическую отчетность;
-
казначейство, управление договорами;
-
выстроить и автоматизировать бизнес-процессы согласований и прохождения документов;
-
построить отчетность МСФО.
Смежные команды, которые работали с нами, автоматизировали:
-
оперативный учет 1С:ERP;
-
строительный контур УСО;
-
бюджетирование.
Представлю команды, с которыми мы работали:
-
Внутренняя команда ИТ-отдела «Текта групп», состоящая из бизнес-аналитика, программиста и технического архитектора. Они понимали, что будут работать еще другие команды, и, чтобы убрать всякий холивар, который мы можем между собой вести, в компанию «Текта» наняли технического архитектора. Он стал нашим судьей, через которого мы могли согласовывать между собой добавляемую функциональность.
-
Koder Line внедряла оперативный учет на базе 1С:ERP и контур «Управления строительной организацией».
-
«ИТАН» автоматизировали финансовый учет и контур управления.
-
И команда Инфостарта внедряла решение Табула.
Как должна была строиться работа на проекте
Конечно, проект автоматизации бизнес-процессов должен был строиться вот так:
-
Постановка задачи, формирование технических требований и создание нормативно-справочной информации.
-
Автоматизация первички.
-
Автоматизация управленческого учета, казначейства, процессов и договоров
-
Бюджетирование.
Но так бывает не всегда.
Проекты каждого подрядчика шли одновременно, поэтому блоки внедрялись хаотично.
Например, нужно выстроить процессы по согласованию договоров, а первички еще нет. Или для плана требовались данные управленческого учета, которого тоже не было.
А заказчику не хотелось переходить на какое-то половинчатое решение, он настоял на том, что внедрение всех подсистем должно происходить одновременно, планировал переходить полностью и сразу.
Именно поэтому применялись гибкие методики. Они доказали свою эффективность и обоснованность в таком хаотичном проекте.
Как мы применяли гибкое управление изменениями и командами
По ходу проекта многие требования пересматривались, изменялись, дополнялись, замещались. Например, учетная политика в управленческом учете за время проекта поменялась семь раз.
Постоянно возникали конфликтные моменты. Например, нам для казначейства требовался график платежей по договору купли-продажи недвижимости, а его еще не перенесла компания, которая внедряла оперативный учет. Таких моментов возникало много.
Но график проекта был жесткий. У нас было всего 4 месяца, чтобы проект заработал в промышленной эксплуатации. При этом точного плана не было: мы не знали, когда у подрядчика-смежника будут готовы все функциональные блоки. Был дедлайн, а как делать, непонятно.
И тогда мы начали применять гибкие методологии. Но у нас это было не в чистом виде – мы использовали гибридные технологии с элементами каскадного проекта и гибкого управления.
Как мы организовали команду на проекте
Наша команда проекта состояла из 19 человек. В общем пуле проекта со всех смежных команд было примерно 60 сотрудников.
С нашей стороны были:
-
руководитель проекта;
-
менеджер проекта;
-
три эксперта;
-
шесть консультантов;
-
пять программистов;
-
два тестировщика;
-
и один методолог.
Мы работали в едином информационном пространстве. Для этого использовали систему «ПланФикс».
Команду проекта с нашей стороны мы разделили на три части – группа управления проектом, группа разработки и тестировщики
Управление проектом. Всю внедряемую функциональность мы поделили на три блока и на каждый из них назначили ответственного эксперта. Эксперты проводили функциональную экспертизу, общались с заказчиком, прорабатывали требования и детализировали их в конкретные задачи для консультантов.
Группа разработки во главе с главным разработчиком. Консультанты ставили задачи программистам и контролировали их исполнение. А координацию этой группы я осуществлял через главного разработчика.
Тестировщики. Одним из важных элементов стало то, что мы выделили отдельную команду тестировщиков.
Особенность проекта состояла в том, что большая часть функциональности не требовала доработок, а реализовывалась на уровне настроек. Поэтому перед запуском в промышленную эксплуатацию:
-
эксперты проверяли настройки;
-
консультанты дополнительно проверяли прохождение всех бизнес-процессов под разными ролями;
-
а тестировщики повторно проверяли за консультантами, что все работает.
Мы тщательно протестировали всю функциональность, чтобы в день запуска люди не столкнулись со сломанной системой.
Какие технологии управления персоналом мы применяли в проекте
С точки зрения управления персоналом применялись следующие технологии:
-
Поэтапное формирование команды. На старте проекта с нашей стороны было шесть человек: три эксперта, я, менеджер проекта и методист. Дальше с каждым этапом команда проекта увеличивалась. На момент запуска у нас уже было 19 человек. Кроме этого, были и внештатные подрядчики, которых мы тоже привлекали. Т.е. с нашей стороны работало до 25 человек.
-
Регламентация работ. Это важно, потому что требуется организовать работу коллег. У нас был свой регламент, который мы назвали «ПРОфис» от слова «проектный офис». Одновременно технический архитектор со стороны заказчика предоставил всем подрядчикам регламент разработки, чтобы все писали с одинаковым качеством. На 50 листах было описано как работать с расширениями, как помещать объекты в хранилище и так далее. Скорее всего, этот документ заказчик разработал в рамках другого проекта, т.е. у них это был уже багажный опыт.
-
Быстрое включение сотрудников в проект. В команду поэтапно добавлялись консультанты, программисты и другие. Для этого применялось наставничество – мы обучали новых сотрудников и передавали им знания.
-
Финансовая мотивация сотрудников позадачно. Чтобы скорость проекта была правильная, в проекте мы четко зафиксировали, что мотивация будет позадачно – выполнил задачу, получил бонус. Этот нехитрый прием позволил получить рост в два раза. Сотрудники брали новые задачи 4-5 раз в месяц.
Как оперативно управлять командой
По оперативной коммуникации по проекту применялись следующие инструменты:
-
Один мессенджер для координации всех участников. Мы выбрали Скайп, потому что заказчик им тоже пользовался.
-
Под каждый вид задачи были созданы групповые чаты: чат по управленческому учету с привлечением группы заказчика, чат по управлению договорами, чат по управлению проекта в целом, чат поддержки и другие.
-
Еженедельные совещания и протоколирование хода проекта с заказчиком. Мы получали информацию о работе подрядчиков и понимали, какие задачи они уже сдали, чтобы мы их подключали к своему модулю. Также на совещаниях фиксировали поручения сторонам и подводили итог проекта.
-
На этапе запуска проводили внутри команды ежедневные планерки по СКРАМ. Это были короткие стендапы по три вопроса: «Что ты делал? Что ты будешь делать? Какие есть сложности?». Иногда бывает такое, что программисты затаивают свои трудности и из-за этого просрачиваются задачи.
-
Делегирование, Совет-банан. Например, делегировали задачу, а сотрудник ее не выполнил и говорит: «Я не знаю как это сделать». В этом случае сотруднику нужно просто дать совет: «Попробуй сделать вот так, и у тебя получится». Так мы оставляем за собой контроль, а за сотрудником – ответственность за выполнение задачи.
-
Технический чат со смежниками. Смежниками я называю команды других подрядчиков, которые работали параллельно с нами. Часть работ была на стыке функциональности. Например, когда другая команда на предпродакшен-базе тестировала процесс закрытия месяца, а нам одновременно требовалось протестировать отражение этих данных в управленческом учете, возникали блокировки. Пришлось это тоже обходить.
Единые мессенджеры, совещания и групповые чаты позволяют всем участникам быть в курсе событий по проекту. Так все команды работали в едином информационном пространстве.
Для управления проектом я использован Канбан-доску. Главное в этом инструменте – обеспечить ровный поток распределения задач, чтобы они не застопорились. Задач было много, около 300-500 штук.
Расскажу, каким образом была настроена доска.
Слева на слайде – бэклог проекта. Это все задачи, которые необходимо выполнить. Они отсортированы по приоритету и срочности.
Мы применяли три простых вида приоритета:
-
Задачи мастхэв, которые должны работать первого числа (запуск проекта был 1 апреля) и никак иначе. Без них заказчик не запустится.
-
Срочные задачи. Их можно было сделать в течение одного-двух месяцев после старта проекта. Они как бы нужны, но не сильно обязательно.
-
Задачи на развитие. Все прочие задачи, которые можно сделать уже по ходу, чтобы улучшить жизнь проекта.
В середине доски отображены задачи текущего спринта. Они сгруппированы по сотрудникам, чтобы можно было свернуть и посмотреть, кто и что делает.
Для текущего спринта мы выделили несколько колонок:
-
Согласование задачи. В ней отражены задачи, которые находятся на согласовании. Например, исполнитель не знает, как делать задачу. Чтобы приступить к работе, нужно получить вводную информацию. Это задачи на второй очереди ожидания.
-
В работе. Это то, что сейчас делается, с какими-то пояснениями.
-
Выполнено, проверить заказчику. Сначала задачи находятся на внутреннем тестировании, а потом попадают на проверку у заказчика. Я смотрел, что сейчас на проверке, кого нужно взбодрить, с каким заказчиком пообщаться, чтобы задачи не зависали.
-
Выполненная. Сюда относятся задачи, которые заказчик подтвердил, проверил, и они уже перенесены в хранилище рабочей базы.
-
Готово. В эту колонку я переносил задачи сам в тот момент, когда включал их в отчет по проекту для заказчика.
Как можно удобно пользоваться анализом выполнения задач
Так как сотрудников и задач было достаточно много, как анализировать выполнение задач?
В ПО, которое мы использовали, это называется «Хроника» – по сути, это лог задач. Сюда сыпятся все события по задачам: какая-то задача выполнена, какая-то переведена в другой статус, какая-то просрочена, по какой-то есть вопрос.
Анализ лога позволяет сильно экономить время. Каждое утро я анализировал лог, быстро его разбирал и был в курсе всех деталей проекта.
Это позволило даже не готовиться к отчету перед заказчиком. Я всегда был готов, потому что знал, что происходит.
Важно отметить, что работа по проекту велась на стыке команд. Было много параллельных задач. Например, подрядчик заканчивал задачу, и ее нужно было сразу подключать к нашему модулю – например, к бизнес-процессам согласования и т.д.
Как осуществлялась координация между смежными подрядчиками
Чтобы координировать работу между смежными командами, мы использовали:
-
Скайп-чат – там мы, в частности, взаимодействовали по бронированию объектов хранилища. Например, подрядчик захватил корень, а нам нужно добавить отчет – мы информировали
-
Если возникали конфликты, мы устраивали совещания и эскалировали вопросы на заказчика. Например, нам для казначейства требовался график платежей по договору купли-продажи недвижимости, а в нем было недостаточно данных. Тогда мы выводили этот вопрос на заказчика – с их стороны приглашали руководителя проекта (им был финансовый директор) и технического архитектора. Собирались, быстро решали, фиксировали в протокол, ставили задачи и подрядчик дорабатывал.
Приведу два примера сложных взаимодействий, где потребовались не совсем стандартные решения:
Веб-портал
Проблема: заказчик поставил задачу реализовать веб-портал, на котором их строительный подрядчик мог ввести акт выполненных работ (АВР). Но АВР к этому времени еще не был готов, а запускать все нужно одновременно.
Решение: это была срочная задача, и бюджет позволял нам нарисовать свою форму АВР, адаптированную под веб, но более упрощенную. И реализовали механизм заполнения данных. С помощью этого временного решения закрыли срочную потребность в форме АВР.
Блок взаиморасчетов
Проблема: заказчику требовался определенный набор аналитик, чтобы разделять авансы и кредиты. Взаиморасчеты требовалось вести по статьям, а типовая конфигурация этого не позволяла. Но нам это потом нужно было учитывать в управленческом учете.
Решение: чтобы сделать качественное ведение взаиморасчетов, мы принимали участие в проектировании и составлении частного технического задания. То есть мы выдвигали свои требования.
Как мы организовывали команду для проведения обучения
Со стороны заказчика новой системой должны были пользоваться 300 сотрудников, среди которых – много ключевых бизнес-пользователей. Нам нужно было их обучить. Вот как мы это делали:
-
На начальном этапе проекта мы проводили экспресс-моделирование – по ключевым задачам делали тестовые примеры и показывали, как это будет работать.
-
Проводили обучение до и после реализации функциональности. Помню, лично проводил обучение по группе управления договоров – там было 80 сотрудников. Т.е. группы пользователь были большого размера.
-
Мы последовательно проходили по всем этапам ведения договоров, и в результате заказчик получил видео-библиотеку по проекту. Очень рекомендую передавать заказчику не только читабельную документацию, но еще и видео.
Как мы организовывали тестирование
Тестирование тоже потребовало определенного подхода с точки зрения кросс-функциональности.
-
Например, для тестирования использовались сценарии, где четко расписывалось, кто и что делает. Например, есть кейс «Выплата ведомости на заработную плату», но мы не знали, как заказчик должен формировать такую ведомость по итогам доработок подрядчика. Для этого мы запрашивали сценарии тестирования у подрядчиков. Они подготавливали пример, и мы там четко расписывали, кто что делает.
-
Как я говорил, мы проводили двойное перетестирование за консультантом или программистом.
-
Разделили тестовые базы – всего в этом проекте было 29 тестовых баз, на которых работали разные сотрудники разных подрядчиков. У нас было 9 тестовых баз.
-
Отмечу важную вещь, которая очень сэкономит время: сразу наполняйте рабочую базу верифицированной нормативно-справочной информацией. В частности, справочниками статей, подразделений и так далее. В нашем случае актуальные данные были залиты в последний момент, поэтому пришлось потратить 50 человеко-часов впустую, чтобы все перенастроить тестовые данные на реальные значения. Важно было заранее загрузить их в рабочую базу и распределить по тестовым с сохранением гуидов.
-
Обязательно протоколируйте изменения. Хотя большую часть функциональности мы внедряли «из коробки», изменения были. Мы просто создали отдельную задачу у себя в «ПланФиксе» и записывали все изменения туда.
-
И, конечно же, рекомендую работать через расширение. Но это – тема отдельного доклада.
Инструменты тестирования, сверки и сдачи смежной функциональности
Для сверки данных мы специально разработали механизм контроля участков учета.
Смысл в том, что нам по каждой операции нужно внедрить управленческий учет так, чтобы суммы в нем соответствовали первичке.
Для этого мы у себя реализовали набор показателей, который в автоматизированном виде производил сверку.
Например, слева – сумма на счетах эскроу в оперативном учете, а справа – в управленческом. Если есть дельта, можно двойным кликом провалиться до первичного документа и посмотреть, где ошибка.
Если бы мы это не настроили, то потеряли бы минимум три недели. Самое главное, что механизм получился настраиваемый.
Приведу пример того, как мы сдавали работы по смежной функциональности. Например, у нас была задача на основании ведомости по заработной плате автоматически формировать заявку на оплату и отправлять ее на согласование
Причем саму ведомость на заработную плату делала другая команда. И это была особенная ведомость: она автоматически загружалась из зарплатной базы и распределялась по аналитике. Смысл их работы заключался в том, что ведомость должна создаваться одной кнопкой, потому что сотрудников в компании 600, а людей, которые рассчитывают зарплату, – двое.
Ведомость формировалась, и на ее основании автоматически формировалась заявка на оплату с запуском ее согласования. Причем, там было очень много моментов, зависящих от видов заработной платы и т.д.
Важно было несколько раз отрепетировать эту функциональность с подрядчиком, чтобы при сдаче работ заказчику не было недопониманий.
Особенности управления командами при запуске проекта
Помимо основной команды внедрения на проекте была команда технической поддержки. Это отдельные специалисты, совсем другие ребята – не те, которые внедряли проект.
Для коммуникации с ними на этапе запуска использовались следующие инструменты:
-
Чаты оперативной поддержки и Service Desk.
-
Управление загрузкой специалистов поддержки, распределение между ними задач.
-
На первом этапе важно участие в команде поддержки специалистов команды внедрения, которые участвовали в этом проекте.
-
Важно передавать им компетенции от команды внедрения к команде поддержки.
-
Четкое ведение проектной документации, чтобы она релевантно передалась в поддержку.
Поделюсь инструментом, который сыграл в проекте одну из ключевых ролей наравне с контролем участков учета – это настраиваемый рабочий стол.
Напомню, что у нас было 27 разделов меню, в каждом из которых от 10 до 30 команд. Можете представить, сколько возможностей по ведению учета есть у заказчика.
Настраиваемый рабочий стол позволил вывести:
-
бюджетные лимиты текущего квартала;
-
ключевые команды;
-
и, что важно, инструкции – например, пользователь открывает свою 1С, а у него на рабочем столе инструкция, как ему работать.
Эти рабочие столы были настроены под разные категории пользователей, и это на первом этапе очень хорошо сработало.
Какие результаты получил заказчик и команда
По итогам данного проекта заказчик получил:
-
Возможность оперативно формировать управленческую отчетность по проектам: Управленческий баланс, Отчет о финансовых результатах, Капитал, ДДС, ОСВ по проектам компании.
-
Возможность получения необходимой аналитики. Теперь можно производить необходимую детальную расшифровку и анализ управленческого учета.
-
Сокращение времени на подготовку и согласование договоров в три и более раз.
-
Исключение потерь документов. Значительно ускорены бизнес-процессы согласования.
-
Настроено формирование договорных документов, включая совместную разработку, визирование, согласование, утверждение и публикацию.
Мы сделали проект, как подтверждает заказчик, за 4 месяца. И самое главное, заказчик получил гибкий инструмент, который он сможет в дальнейшем донастраивать и развивать самостоятельно.
Помимо того что заказчик получил результат, его получила и наша команда.
Для нас этот проект – номер один по сложности. Результат:
-
Укрепилась вера в себя и в продукт. После такого проекта можно сделать практически любой.
-
Смежники из разных команд стали понимать друг друга лучше.
-
Усилилось доверие коллег.
-
Возросла мотивация у команд. Переболели и переросли страхи.
-
Получили очень полезный опыт. Например, я настолько круто автоматизированного казначейства, управленческого учета и управления договорами вообще нигде не видел.
-
Сотрудники не выгорали. Это получилось, потому что ими эффективно проводилось управление с помощью инструментов, которые я указал в докладе.
-
Получили финансовую мотивацию.
Компетенции руководителя проекта. Советы и выводы
Какие должны быть качества у руководителя проектов, чтобы делать такие проекты:
-
Работа в команде. Ты, как руководитель проекта, должен быть и внутри команды, и, конечно же, немного над ней. Быть лидером, но не делать все за команду. Понятно, что есть крутые специалисты, которые могут сделать все, в том числе как руководители проекта. Но надо слушаться команду, доверять ей. Решения, принятые внутри команды, воспринимаются легче.
-
Позитивный настрой, несмотря на жесткие сроки.
-
Вовлеченность. Надо быть в курсе всех деталей и нюансов проекта, чтобы эффективно им управлять. Тут без инструментария не обойтись – мне очень помогли лог работы команды и доска Канбан.
-
Стрессоустойчивость, ответственность и компетентность. Представьте, что все ваши сотрудники заболели. Вы должны довести какие-то задачи до логического завершения или быстро нанять подрядчиков, или привести в команду новых сотрудников и передать им знания об этом проекте.
-
Мотивация на результат.
Ключевые советы для успешного управления командами:
-
Обменивайтесь опытом. Обсуждайте внутри команды все проблемы, задачи и совместно ищите решения.
-
Собирайте автономные и многофункциональные команды, которые способны комплексно и самостоятельно решить необходимые задачи.
-
Проводите еженедельные, а лучше на первом этапе ежедневные совещания с командой, чтобы быть в курсе всех деталей проекта.
-
Используйте сценарии тестирования и сценарии сдачи работ, если ваша функциональность зависит еще от кого-то – от заказчика, от другого подрядчика и т. д.
-
Используйте продукты-конструкторы. Гибкие технологии отлично совмещаются с гибкими продуктами, чтобы при совершении новых изменений всегда была возможность что-то отрегулировать в самом конструкторе, не переписывая продукт.
-
Используйте автоматизированные инструменты сверки данных – это очень помогает на больших проектах.
-
Применяйте визуальные инструменты управления командами типа доски Канбан, чтобы быть в курсе всех деталей и распределять поток задач.
Вопросы
Как вы синхронизировали 29 тестовых баз на моменте тестирования?
Как я уже говорил, нормативно-справочная информация в этих базах была разрозненная, но мы в своих тестовых базах старались брать реальные примеры из бизнес-процессов заказчика.
В частности, мы делали базы препродакшн, в которых наш смежник делал тестовый пример, и мы на этом примере все проверяли.
Но это очень тормозило работу. Если бы мы управляли этим проектом, то делали все не так – мы бы реализовали единую тестовую базу со всеми введенными модельными примерами.
Мы такую базу просили у подрядчиков за месяц до запуска проекта в продакшен, но нам ее дали за неделю. Так получилось.
Коронавирус нам немного помог. Из-за того, что все пользователи были удаленные, меньше был документооборот. Поэтому мы эффективнее запустились. Но это было не просто. Я чуть бы не поседел за первую неделю запуска проекта, когда вдруг 300 пользователей начали работать.
Как назывался продукт, в котором вы использовали доску Канбан?
Это решение называется «ПланФикс». Это инструмент-планировщик, но его надо уметь настраивать. Свою вариацию настройки мы посмотрели в блоге «ПланФикса». Нам очень зашло, потому что все процессы видно, и можно подитоги настроить. Мы в человеко-часах работали. Мы смотрели – у нас такой объем задач, и такое количество сотрудников. Хватит ресурсов или нет? Хватило вроде.
На проекте внедрения были проблемы с коммуникацией с заказчиком? Часто люди со стороны заказчика очень загружены своей работой и не могут быть сильно вовлечены в проект. Как вы решали такие проблемы?
Нам повезло, что в этом проекте таких проблем было меньше всего. Там была очень мотивированная команда. Они все были опытными пользователями Navision.
Самая страшная фраза, которую я слышу, когда прихожу в проект – «Мы первый раз делаем такой проект. Раньше не работали в таких учетных системах. Только в Экселе». Тут все-таки ребята работали в Navision, а Navision тоже хорошая процессная управленческая система.
Там финансовый директор сразу мотивировал свою команду, чтобы они выделяли время под нас. Поэтому с вовлеченностью заказчика практически не было проблем.
Мы заранее все планировали – были собраны рабочие группы, и в каждой из них со стороны заказчика был лидер, помимо финансового директора.
Конечно, потом были дополнительные уточнения, какие-то задачи новые появились, которые вообще не планировали делать.
Но опять же, применение гибких инструментов и гибких технологий очень помогло.
Как вы думаете, руководитель должен понимать ту предметную область, в которой он внедряет проект?
Я считаю, что руководитель должен понимать предметную область. У меня по-другому не получается. У меня три руководителя проекта, и в процессе их поиска мы прошли много итераций найма. В нашем случае, я вообще не представляю, как руководитель проекта будет на таких сложных задачах разговаривать с заказчиком без экспертизы в конкретном бизнес-направлении,
Я считаю, что менеджер или администратор может не иметь образование в этой предметной области, а руководитель проекта должен. По крайней мере, у него должен быть опыт работы в данном направлении, отрасли или функциональной области.
|
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse. Больше статей можно прочитать здесь. Приглашаем на мероприятия Инфостарта 2023 года:
|
