ИТ-экспертЕвгений Горшковhttps://teletype.in/atom/wangoff2026-05-25T20:50:57.822Zwangoff:QYu1PHRwBWw2021-08-22T21:07:31.650Z2021-08-22T21:59:14.067Z

<img src="https://img2.teletype.in/files/df/c1/dfc129bd-dea4-4bd7-acbe-4328b7b957da.png">Всем привет. Давненько ничего не писал. Вот, решил структурировать текущие представления о том, как устроен корпоративный ИТ-рынок с точки зрения ролей внутри ИТ-интеграторов.

<p>Всем привет. Давненько ничего не писал. Вот, решил структурировать текущие представления о том, как устроен корпоративный ИТ-рынок с точки зрения ролей внутри ИТ-интеграторов.</p> <p>Описал основные роли в ИТ-проектах. А затем посмотрел, как обстоят дела в корпоративном ИТ на примере самой популярной платформы в РФ - 1С.</p> <p>Ни в коем случае не претендую на истину - корп.рынок закрыт, слабо структурирован и различается по масштабу, культуре и задачам. Всего лишь излагаю свое понимание как оно есть, надеюсь оно найдет пересечение с вами.</p> <p>Референсная область: 1С. потому что а) популярно; б) известна мне лучше остальных. В остальных областях могут быть небольшие отличия, но спроецировать можно. Например, где-то есть UX/UI, побольше релиз-менджеров. Но чем дальше от производства - тем больше роли пересекаются по задачам и количеству специалистов.</p> <p><strong>Пост может быть полезен для:</strong></p> <ul> <li>Тех, кто хочет понять, куда расти</li> <li>Тех, кто хочет понять, какая роль ему ближе</li> <li>Помочь с позиционированием себя на хх</li> <li>Подсказать, куда может развиваться компания</li> <li>Дать словарь для сопоставления разных орг.структур в компаниях </li> </ul> <p><strong>Ограничения</strong>: </p> <ol> <li>Это не научная работа, а скорее структурированное изложение моего представления</li> <li>Даже эта модель - очень общая и в каждой конкретной компании те или иный роли могут отличаться как по функционалу, так и по совмещению ролей в одном человеке</li> <li>Акцент сдела на заказное внедрение. То есть - не создание продуктов, а их внедрение в кровавом энтерпрайзе</li> <li>Взгляд - со стороны исполнителя проектов внедрения. Внутри бизнеса еще много интересных ролей, которые задействованы в нанесении пользы. Таке, как владелец продукта, функциональный заказчик, ИТ-менеджер и тд</li> <li>Структура дана не по PBMoK, где есть уставы, спонсоры и кураторы, но по ролям внутри компании, как я их вижу и понимаю прямо сейчас</li> </ol> <p></p> <p data-align="center"><strong>Обобщенная ролевая модель</strong></p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img2.teletype.in/files/df/c1/dfc129bd-dea4-4bd7-acbe-4328b7b957da.png" width="946" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Разработчик </strong></h2> <p>Пожалуй, самая понятная роль - разработчик 1С. По теме миллион статей, рассуждений, чатиков и тд. Разработчик 1С - это то в первую очередь тот, кто пишет код. А дальше по обстоятельствам. Может быть и тестировщиком, и архитектором, и девопс-инженером.</p> <p>Одна из самых поулярных вакансий на рынке. Стать разработчиком просто (с точки зрения доступности материалов) - начиная от курсов, заканчивая оплачиваемыми стажировками в фирмах-франчайзи 1С.</p> <p></p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img2.teletype.in/files/5f/6e/5f6ecee0-34fa-466d-ba18-330aee3dd0af.png" width="1660" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Аналитик </strong></h2> <p>Я определяю позицию как классчиеский Системный аналитик со знанием 1С. Но на рынке, как правило, под аналитиком 1С понимают системного аналитика со знанием платформы 1С, предметной области (1 или более - бухгалтерия, бюджетирвоание и тд), а так же с навыками консультирования и чуть-чуть разработки.</p> <p>Занимается, в том числе, подготовкой проектных решений, постановкой\приемкой задач разработки, демонстрациями, пресейлами.</p> <p>На данный момент не вижу на рынке четкого разделения между Аналитиком и Консультантом. Но кое-где оно все же есть. Например, там где производство четко поделено на внедрение и поддержку.</p> <p>Вход в профессию также неплохо изучен. Как правило, аналитик получается: </p> <ul> <li>из работчика</li> <li>из бывшего специалиста в предметной области (бухгалтер, например)</li> <li>вырастает с млашдих позиций в компаниях, которые готовы растить стажеров, джунов до состоявшихся аналитиков</li> </ul> <p>Материалов масса как по системному анализу, так и по предметке.</p> <p>Плохо: думать, что аналитик только анализирует</p> <p>Хорошо: думать, что аналитик анализирует, а затем создает артефакты в виде проектных решений, постановок, демо и тд.</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img1.teletype.in/files/87/bc/87bcb976-5e9e-4c67-8ee7-3ec412610ebd.png" width="1668" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Консультант </strong></h2> <p>Четкого определения на рынке не вижу. На текущий момент можно определить консультанта как не-разработчика, который занят преимущественно:</p> <ul> <li>Консультациями пользователей</li> <li>Отработкой запросов в таск-трекере (1-2 линия поддержки)</li> <li>Проводит первичные интверью</li> </ul> <p>В глубокой теории, консультант не так хорош в подготовке проектных решений, как аналитик. Но на практике, один и тот же человек выполняет обе роли, в зависимости от стадии реализации проекта и характере производства - проект или поддержка.</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img3.teletype.in/files/67/ba/67ba5f1e-0d87-408d-889a-7861e78d30c4.png" width="1696" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Тестировщик </strong></h2> <p>Сами видите, что запроса на рынке на такую позицию почти нет. В идеале, это отдельный человек, который тестирует разработку, как правило вручную. Потому что не вручную - это уже QA. </p> <p>На практике, тестируют разрабы, аналитики. Иногда - пишутся автотесты.</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img2.teletype.in/files/5b/21/5b21c3c8-28ef-4eb9-a585-f6d8844ab6c2.png" width="1662" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Методолог </strong></h2> <p>Не самая распространенная роль. Но тем не менее, она есть. По ощущениям, методологи чаще всего требуются:</p> <ul> <li>При разработке продуктов (например, компания пишет свое решение для операционного лизинга, нужен методолог)</li> <li>На больших корпоративных проектах, где есть время и деньги на выделение роли метолога, как и на полноценную разработку регламентов и описание процессов</li> </ul> <p>Нередко вижу, как методологами называют крутых аналитиков, что не всегда верно, хотя и возможно. </p> <p>Методолог не обязан уметь в проектирование и корп.архитектуру. Он вообще не обязан уметь в проектные методики. Зато обязан быть в курсе новостей отрасли и регуляторов. Неплохо, когда методолог понимание в особенности технологической платформы, дабы не изобретать труднореализуемые рекомендации для команды внедрения/разработки.</p> <p>Плохо: применять методолога как аналитка</p> <p>Хорошо: привлекать на этапе разработки методик/регламентов/процессов; на этапе верификации проектных решений. Все исходящие результаты работы должны загружаться в аналитиков (а точнее, в главного по аналитике, он же как правило - функциональный архитектор)</p> <p>Откуда брать: из аналитиков, из экспертов в предметной области, из консалтеров (не путать с Консультант)</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img4.teletype.in/files/30/62/306281d6-7ddc-4ef5-afdc-1badd63a71be.png" width="1648" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Архитектор </strong></h2> <p>На практике - либо самый крутой разраб, либо самый крутой аналитик, который отвечает за содержание проекта.</p> <p>Главное, что нужно знать архитектор отвечает за технологию и непосредственно производство. А сколько их там, и кто конкретно за разработку, а кто за аналитику - вариативно.</p> <p>Технический архитектор отвечает за технологию и вообще всю разработку. Верифицирует проектные решения, готовит те проектные решения, где описаны технические аспекты. С недавних пор - еще и за CI/CD контур (это про правильные обновления и тестирование)</p> <p>Функциональный архитектор - тот, кто отвечает за </p> <ul> <li>Итоговое содержание системы</li> <li>За технологию и вообще производство аналитического блока</li> </ul> <p>В зависимости от сложности и характера задачи - могут быть нужны оба, может только технический, может тольок функциональный. В 1С, например, роль такого функционального архитектора выполняет Руководитель проекта. Потому-то руководители проектов зачастую имеют больше скилов в реализации содеражния, чем во всех остальных раздела проектного менеджмента.</p> <p>Вообще говоря, конфигурации могут быть самыми разными. Но роли так или иначе присутствуют</p> <p>Я предпочитаю называть Функционального архитектора тимлидом. Который отвечает за стрим или весь проект, в зависимости от масштаба. Тимлид активно координируется с РП и техническим архитектором, если он есть.</p> <p>Возможные названия из этого раздела:</p> <p>РП, архитектор, техлид, тимлид, технический архитектор, функциональный архитектор, главный аналитик, главный разработчик</p> <p>Откуда расти: из произвоства. Разрабы, аналитики.</p> <figure class="m_column"> <img src="https://img1.teletype.in/files/c0/2e/c02e59d3-febc-4ef5-b75c-c98ce28cd1f1.png" width="1682" /> </figure> <hr /> <h2 data-align="center"><strong>Руководитель проекта</strong></h2> <p>В идеале - РП отвечает за итоговый результат проекта. А именно:</p> <ul> <li>Содержание</li> <li>Бюджет</li> <li>Сроки</li> <li>Удовлетворенность клиента</li> </ul> <p>На деле, РП может быть как политической ролью, так и боевым тимлидов с функциями администратора. В зависимости от бекграунда, может быть сильнее прокачана область тимлидерства, администрирования, корпоративного перекладывания ответственности, управления ФОТ, презентаций, управление продуктом и тд.</p> <p>Так что ответить на вопрос Кто такой хороший РП сложно - слишком разные требования в разных местах. Но на мой взгляд, хорший РП точно обязан:</p> <ul> <li>Оказывать качественный сервис команде проекта и помогать ей делать свою работу</li> <li>Уметь планировать, контролировать и отслеживать бюджеты</li> <li>Управлять ожиданиями клиента</li> <li>Работать с негативом</li> <li>Уметь ясно и кратко излагать мысли</li> <li>Уметь адаптировать стиль управления в зависимости от команды и заказчика</li> <li>Уметь вовремя и грамотно эскалировать проблемы и риски проекта</li> <li>Делегировать</li> <li>Уметь проводить презентации</li> </ul> <p>Откуда брать: </p> <p>Из аналитиков, растить с нуля. Изредка - из разрабов, но те как правило проходят сперва метаморфозу в аналитиков.</p> <p></p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img1.teletype.in/files/00/c0/00c0d4b5-524e-4887-b842-79e85c027a39.png" width="1658" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Product manager</strong></h2> <p>Не самая распространенная позиция. Но она и нова. По факту, данная роль необходима при разработке продуктов или реализации продуктообразных проектов. </p> <p>Пока что по ощущениям, запрос на рынке на такую позицию отсутствует. По крайней мере, в 1С. Несмотря на то, что деятельность по созданию продуктов в той же 1С - осуществляется активно и регулярно.</p> <p>Откуда брать:</p> <p>Из аналитиков, растить с нуля. Изредка - из разрабов, но те как правило проходят сперва метаморфозу в аналитиков. Ну или растить.</p> <p></p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img2.teletype.in/files/d6/e5/d6e5b2f8-2bd7-4a1a-bf84-bd4cc5a94264.png" width="1666" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Руководитель направления </strong></h2> <p></p> <p>Уровень мидл-менджмента. Направление может определяться продуктом, предметной отраслью, составом подчиненных</p> <p>Главное отличие от менеджера проекта - деятельность носит процессный характер.</p> <p>Как правило, проекты реализуются в рамках определенного направления. То есть, когда запускается проект внедрения 1С:УХ, руководитель направления выделяет ресурсы под проект. При этом, РП может быть как внутри направления, так и отдельно, в рамках проектного офиса.</p> <p>Нередко руководитель направления выполняет роль куратора, BDM, аккаунта.</p> <p>Что может быть в KPI:</p> <ul> <li>Выручка по направлению</li> <li>Маржинальность проектов</li> <li>Объем продаж</li> <li>Количество сертификатов</li> <li>Количество сотрудников</li> <li>Рост квалификации</li> <li>Количество запущенных проектов</li> </ul> <p> Откуда брать:</p> <p>На усмотрение руководства. Как правило, это так или иначе бывшие РП.</p> <p> </p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img3.teletype.in/files/ed/77/ed77bba9-5fcc-4e9a-9b46-1c0a99ef91eb.png" width="1656" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Руководитель отдела </strong></h2> <p>Почти то же самое, что и руководитель направления, только одела. А вакансий заметно больше. </p> <p>По ощущениям - РО это действительно РН, только чаще он определяется либо по порфтелю проектов под ним, либо по числу сотрудников.</p> <p>Задачи те же, но как мне кажется, фокус может быть размыт чуть больше.</p> <p>Бывают такие вариации, когда в компании есть РО разработки, РО аналитики, Руководитель проектного офиса. По сути, РО - это классический мидл-менеджер в орг.структуре предприятия.</p> <p>Не будем забывать про РО инхаус. Как правило, это отдел внутри ИТ-департамента, к которому приписаны разработчики, аналитики, менеджеры (реже).</p> <p> Откуда брать:</p> <p>На усмотрение руководства. Как правило, это так или иначе бывшие РП, разработчики, аналитики.</p> <p></p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img3.teletype.in/files/a7/c6/a7c6ff41-a009-4717-9e9e-d41c2ef8ac5c.png" width="1670" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Business development manager </strong></h2> <p>Пошли новые термины. </p> <p>По факту, BDM сегодня - это менеджер по продажам, только красивше. Чтобы продажники чувствовали себя важнее. </p> <p>Но на самом деле, роль крайне важная. BDM - это человек, который конструирует красивое и реализуемое будущее для клиента. И под это будущее запускает один или программу проектов. </p> <p>Важнно помнить, что BDM в не-ИТ аутсорсе решает иные задачи - вывод на рынок, развитие бизнеса в целом и тд. </p> <p>BDM: </p> <ul> <li>Больше ориентирован &quot;внутрь&quot;, чем сейлз или аккаунт</li> <li>Хорошо знает технологии внедрения </li> <li>Хорошо ориентируется в бизнес-задачах</li> <li>Умеет подружить ИТ и бизнес</li> </ul> <p>Вот небольшая схема о месте BDM (по версии имени меня)</p> <p>Откуда брать:</p> <p>РП, Продакты.</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_original"> <img src="https://img1.teletype.in/files/cb/e6/cbe64de9-3f8e-4eb6-81f9-0d40ecc7cc47.png" width="889" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Аккаунт </strong></h2> <p></p> <figure class="m_column"> <img src="https://img4.teletype.in/files/3e/2f/3e2f8c7b-c936-40aa-a3fc-6d6e5567f4c7.jpeg" width="364" /> </figure> <p>Коротко - печень на ножках.</p> <p>Его задача - выстраивать долгосрочные отношения с клиентом. И закладывать основы для будущих продаж.</p> <p>Аккаунт не участвует во внедрении, принимает участие в продаже. Генерирует лиды по клиенту.</p> <p>Аккаунт активно вмешивается в проект, если: </p> <ul> <li>Наносится ущерб долгосрочным отношениям</li> <li>Наносится ущерб его KPI по клиенту</li> <li>Нужна помощь с выходом на ЛПР высокого уровня</li> </ul> <p>Главное качество аккаунта - уметь дружить и иметь связи. Хорошие аккаунты ездят на очень хороших машинах и подчиняются непосредственно CEO.</p> <p>В 1С, например, главный аккаунт чаще всего - это директор франчайзи.</p> <p>Откуда брать:</p> <p>Менеджеры по продажам, BDM, люди со связями в отрасли - бывшие CEO, CIO</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img2.teletype.in/files/5c/23/5c230382-c1b5-4b6b-bf91-ff34014c4233.png" width="1662" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Менеджер по продажам </strong></h2> <p>Может быть двух типов: </p> <ul> <li>Непосредственно, менеджер по продажам, с функционалом обзвонов, подготовки КП и планом продаж</li> <li>Корпоративный менеджер, который скорее помогает в организации сделки. В таком случае он &quot;под&quot; аккаунтом.</li> </ul> <p>KPI МП могут быть такими: </p> <ul> <li>Объем продаж</li> <li>Выручка</li> <li>Оплаты (cash flow) </li> <li>Какие-то Kpi по холодным продажам</li> </ul> <p>Мне кажется, что задачи менеджера по продажам очень сильно отличаются от компании к компании. Но как правило, он все же не владеет компетенциями производства. В идеале, хороший менеджер по продажам в будущем становится аккаунтом, а рутину передает ассистентам или другим менеджерам по продажам.</p> <ul> <li>Оплаты (cash flow) </li> <li>Какие-то Kpi по холодным продажам</li> </ul> <p>Мне кажется, что задачи менеджера по продажам очень сильно отличаются от компании к компании. Но как правило, он все же не владеет компетенциями производства. В идеале, хороший менеджер по продажам в будущем становится аккаунтом, а рутину передает ассистентам или другим менеджерам по продажам.</p> <p>Также мне кажется, что большинство вакансий по запросу на хх - это продажники с функцией холодного обзвона клиентов. Проверить можете сами.</p> <p>Откуда брать: </p> <p>чаще всего с hh.ru</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img4.teletype.in/files/74/18/7418ba5c-8b0e-49b7-9e52-c6a5c30720e1.png" width="1660" /> </figure> </section> <hr /> <h2 data-align="center"><strong>QA</strong></h2> <p>Если коротко и обобщенно - человек, который умеет наладить и проводить автоматизированное тестирование. Редкий зверь пока что. Но девопс развивается, а с ним и инструменты автоматизированного тестирования. С точки зрения физики, смысл в QA появляется в продуктовой разработке.</p> <p>Откуда брать:</p> <p>Растить из разрабочтиков или хантить с рынка.</p> <p></p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img4.teletype.in/files/7f/31/7f310661-d87d-4b26-9c7e-c534a252d622.png" width="1670" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Devops</strong></h2> <p></p> <p>Здесь как правило ожидается специалист, который может развернуть поддерживать CI/CD контур. </p> <p>Это значит, что при разработке обновления будут проводиться чуть более праваславно, чем вручную. Тестирование будет происходить автоматически, будут всякие аналитические панели со статистикой ошибок и технического долга.</p> <p>Стоят дорого, требуется далеко не везде. Перспективная область профессионального развития. </p> <p>Откуда брать:</p> <p>Растить из разрабочтиков или хантить с рынка.</p> <figure class="m_column"> <img src="https://img4.teletype.in/files/f8/28/f8280511-3f6a-4ff7-907e-954c4feac88a.png" width="1670" /> </figure> <hr /> <hr /> <h2 data-align="center"><strong>Релиз-менеджер 1С</strong></h2> <p>Почти не ищут такого специалиста. Его задача - обеспечить прозрачное, стабильное и документированное донесение релизов до продуктивной системы.</p> <p>Это может выражаться как в аккуратном собирании задач в Жире и оформлении их в релиз, описанием изменений.</p> <p>Так и в применении CI контура для автоматических деплоев. </p> <p>Откуда брать:</p> <p>Растить из аналитиков, разработчиков, хантить с рынка.</p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img3.teletype.in/files/2e/de/2ede9cd4-5c40-4b08-b042-23a50890bf72.png" width="1676" /> </figure> </section> <hr /> <h2 data-align="center"><strong>Специалист 1С</strong></h2> <p></p> <p>Пережиток прошлого. Специалист на все руки. Часто требуется в инхаус. Огорчает большое количество вакансий на эту тему.</p> <p>Специалист-мультиинструменталист. И пишет код, и тестирует, и ругается с пользователеями, и управляет проектом. </p> <p>Работа в такой роли приводит к выгоранию, клинической депрессии и уходу в геймдев.</p> <p>Откуда брать:</p> <p>Если вам нужны такие люди - лучше задумайтесь над большими изменениями в компании.</p> <figure class="m_column"> <img src="https://img2.teletype.in/files/58/66/58669d6d-25d6-48df-b2cc-b8e69a04f225.png" width="1658" /> </figure> <hr /> <hr /> <h2 data-align="center"><strong>UX 1С</strong></h2> <p>Дизайнер пользовательского опыта. Крайне редко требуется при разработке единичных продуктов на платформе 1С. Увеличивает стоимость продукта. Применение в 1С ограничено наличием автоматически генерируемых форм. </p> <p>Качество интерфейсов контролируется адекватностью проектной команды и бизнес-заказчика.</p> <p>Откуда брать:</p> <p>Вероятнее всего, с рынка. </p> <section style="background-color:hsl(hsl(0, 0%, var(--autocolor-background-lightness, 95%)), 85%, 85%);"> <figure class="m_column"> <img src="https://img1.teletype.in/files/46/0c/460cbb08-f2f5-479d-b0df-3c939183df20.png" width="1692" /> </figure> </section> wangoff:lF3poXM1M9L2021-08-22T18:57:37.380Z2021-08-22T18:59:29.864Z

Написать в телеграм e-mail: wangofflive@gmail.com

<p><a href="http://t.me://iwangoff" target="_blank">Написать в телеграм</a><br />e-mail: wangofflive@gmail.com </p> <p><a href="https://t.me/RussianAutomatization" target="_blank">тг-канал</a></p> <p><a href="https://t.me/RuAutomatizationChat" target="_blank">Чат в телеграм</a></p> <p><br /><a href="https://youtube.com/channel/UCYbPgnF0VBLvEMo9cR7Qbiw" target="_blank">Youtube </a></p> wangoff:7vlyyQWFCZP2021-08-22T18:54:35.459Z2021-08-22T18:54:35.459Z

<img src="https://static.wixstatic.com/media/137802_39158b78d78740b482e406a4ba7e5b81~mv2.jpg/v1/fill/w_376,h_360,al_c,q_80,usm_0.66_1.00_0.01/%25D1%258F%2520%25D0%25BA%25D1%2580%25D1%2583%25D0%25BF%25D0%25BD%25.webp">Горшков Евгений Андреевич.

<h2>Экспертная консультация об автоматизации в ИТ и на 1С</h2> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_39158b78d78740b482e406a4ba7e5b81~mv2.jpg/v1/fill/w_376,h_360,al_c,q_80,usm_0.66_1.00_0.01/%25D1%258F%2520%25D0%25BA%25D1%2580%25D1%2583%25D0%25BF%25D0%25BD%25.webp" width="376" /> </figure> <p>Горшков Евгений Андреевич.</p> <p>Сертифицированный руководитель проектов. В ИТ с 2007 года.</p> <p>За это время накопил опыт в решении задач автоматизации бизнеса, которым хочу делиться.</p> <p>​</p> <p>Проект года по версии 1С, Проект года по версии Global CIO. Имею опыт разработки, консалтинга, управления, в т.ч. кризисными проектами. Делал проекты для Авито, Абрау-Дюрсо, Ростех, Медси, Содружество и других уважаемых компаний.</p> <p>Помимо основной работы, консультирую людей про ИТ и про 1С. Подробнее об этой деятельности - на текущей странице.</p> <p>Реальные истории</p> <p>Автоматизация автосервиса. Малый бизнес.</p> <p>​</p> <p>Исходное состояние: Владельца автосервиса не устраивает текущий набор программ для работы автосервиса. Хотел написать свой продукт на 1С. Искал подходящих фрилансеров.</p> <p>​</p> <p>Что дала консультация: шаг №1 - попросил описать на бумаге свое видение ситуации. В итоге родился документ, похожий на ТЗ. Уже в процессе написания человек многое понял о своей задаче. Далее - в процессе обсуждения задачи объяснил нюансы работы с облачными решениями, стоимостью владения собственным продуктом. Указал на подходящий продукт и направил в сторону изучения демонстрационной версии. Расписал шаги по автоматизации и о вариантах привлечения сотрудников.</p> <p>Эффект: владелец бизнеса из состояния &quot;я не знаю, что делать и сколько это стоит&quot; перешел в состояние &quot;я знаю, какие дальнейше шаги, какие риски и к кому обращаться, на что обращать внимание&quot;. Избежал риска пустой траты денег на неправильную автоматизацию с неправильными людьми на неправильном продукте.</p> <p>​</p> <p>​</p> <p>Автоматизация казначейства. Средний бизнес.</p> <p>​</p> <p>Исходное состояние: Медицинский стартап узнал о том, что на рынке есть продукт 1С:Управление холдингом. Решил инвестировать деньги в автоматизацию процессов согласования платежей с помощью данного продукта. Начал искать исполнителя на проект автоматизации.</p> <p>​</p> <p>Что дала консультация: выяснили текущий уровень зрелости компании и бюджет. Определили степень регламентации бизнес-процесов и основную статистику процессов (число пользователей, платежей). Определили основные задачи. Рекомендовал заказчику продукт на 1 млн.руб. дешевле и отговорил запускать проект, который приведет к затратам в несколько миллионов рублей. Вместо этого предложил взять за основу более простой продукт, который покрывает задачи бизнеса, рекомендовал нужных партнеров. Проинструктировал о правильной организации работ, обозначил важность выделения отдельного ответственного от бизнеса на задачу автоматизации. Заказчик за 3 месяца автоматизировал свои процессы с минимальным привлечением внешних подрядчиков</p> <p>Эффект: благодаря часовой встрече, стартап получил эффект от автоматизации через три месяца с прямыми затратами 500 т.р. вместо проекта на несколько миллионов рублей с неясными перспективами.</p> <p>​</p> <p>​</p> <p>Помощь в поиске специалиста в штат</p> <p>​</p> <p>Исходное состояние: оптовый дистрибьютор не мог найти специалиста 1С в штат. HR умели подбирать экспедиторов, но не специалистов в штат из 1 человека.</p> <p>​</p> <p>Что дала консультация: определили главные задачи искомого сотрудника. Определили приемлемый уровень дохода в вакансии. Подготовили проивлекательную вакансию. Снабдили инструкцией по отсеву и тестовыми заданиями.</p> <p>Эффект: после полугода безуспешных поисков, за месяц наполнили воронку кандидатов. Еще через месяц на работу вышел квалифицированный специалист по УТ 11.</p> <p>​</p> <p>Кризисные проекты</p> <p>​</p> <p>За последние годы в моей практике случлось несколько кризисных проектов, в которые я заходил на этапе &quot;все либо плохо, либо очень плохо&quot;</p> <p>​</p> <p>В результате, проекты были выведены из крутого пике. Остановлен хаос. Прекращена работа над задачами, которые не нужны ни заказчику, ни проекту. Налажена работа команды внедрения. Налажена работа по управлению требованиями и границами. Распределены роли. Определены регламенты работы. Получены бизнес-результаты. Произведено актирование работ, заключены договоры на развитие системы.</p> <p>​</p> <p>​</p> <p>Как это работает</p> <p>Для кого это нужно?</p> <p>1. Если вам недоступен квалифицированный эксперт по автоматизации, заслуживающий доверия</p> <p>2. Если вы хотите получить альтернативный взгляд на происходящее</p> <p>3. Если у вас складывается кризисная ситуация на проекте, но никто не может честно ответить на вопрос, в чем причина</p> <p>О чем имеет смысл спросить</p> <p>​</p> <p>Кризис на проекте. Почему проект буксует; Компетентна ли команда; Что не так с бизнес-задачей; Что делать;</p> <p>​</p> <p>Старт проекта. Адекватность целей проекта; Адекватность бюджета и сроков; Выбор команды; Выбор технологии и продукта; Адекватность бюджета; Определение целей проекта; Адекватность сроков; Возможные риски;</p> <p>​</p> <p>Автоматизация мелкого и среднего бизнеса. С чего начать и куда двигаться; Как подобрать исполнителей; Выбор продуктов; Выбор стратегии; Бюджеты; Риски</p> <p>​</p> <p>Как получить консультацию</p> <p>Шаг 1. Оставить заявку на этом сайте. Описать суть запроса, Представиться, Оставить свои контакты телеграм</p> <p>Шаг 2. Получить фидбек на заявку в течение суток. Узнать цену, узнать, имеет ли шанс консультация быть полезной. Узнать, что нужно подготовить перед консультацией</p> <p>Шаг 3. Оплатить</p> <p>Шаг 4. Запланировать и провести консультацию. В Зуме, не под запись. Все конфиденциальные материалы будут демонстрироваться с экрана заказчика без передачи. Длительность – до 100 минут</p> <p>​</p> <p>Примечание: для чувствительных данных возможно заключение NDA</p> <p>Если оформлять заявку сложно и неудобно, либо если есть персональный запрос - напишите мне в телеграм @iwangoff</p> <p>​</p> <p>Чем вы рискуете</p> <p>Риски, которые вы несете - это стоимость разовой консультации и затраченное время. Время измеряется часами, деньги измеряются несколькими часами работы рядового специалиста в интеграторе.</p> <p>Зачем это нужно?</p> <p>Есть много способов получить консультацию - если вы большая и крупная компания - можно обратиться в ДИТ. Можно позвонить партнеру 1С и заказать у них не только консультацию, но и демонстрацию продукта. Можно спросить у знакомых.</p> <p>​</p> <p>Но можно проконсультироваться здесь. Зачем?</p> <p>1. Объективность ответов. Я не хочу продать конкретный продукт или конкретных исполнителей. У меня нет искажений, которые возникают при взгляде на ситуацию изнутри</p> <p>2. Опция &quot;спросить у своих&quot; - всегда остается. И мой совет очень часто содержит в себе рекомендацию обратиться в ДИТ с конкретными вопросами, или к партнерам 1С с не менее конкретными вопросами.</p> <p>3. Вы точно знаете, с кем общаетесь. С действующим экспертом в автоматизации. При обращении в незнакомый интегратор - вы, возмжно, получите не менее квалифицированного специалиста. А возможно и нет. Возможно, это будет менеджер по продажам или стажер, который умеет демонстрировать типовые решения. Для среднего и мелкого бизнеса мало кто готов выделять лучших специалистов на разовые консультации</p> <p>​</p> <p>Чего не стоит ожидать</p> <p>Экспертная частная консультация не предполагает:</p> <p>1. Демонстрацию типовых продуктов 1С</p> <p>2. Проведение работ по настройке системы, подготовке документации, разработке</p> <p>3. Выдачу коммерческих секретов моей основной деятельности</p> <p>4. Ответственность за Ваше решение</p> <p>​</p> <p>Бонус за привлечение</p> <p>Если вы порекомендуете консультацию, Вы получите 10% бонус по факту консультации. Для этого необходимо, чтобы Ваш ник был указан в форме заявки.</p> wangoff:TMpDtFhjAZw2021-08-22T18:53:42.090Z2021-08-22T18:53:42.090Z

Мы в сообществе накраудфандили ресурсы для саморазвития.

<p>Мы в <a href="https://t.me/RussianAutomatization" target="_blank"><u>сообществе </u></a>накраудфандили ресурсы для саморазвития.</p> <p>Удобно выложить не получается, потому просто приложу <a href="https://docs.google.com/spreadsheets/d/17VyJcBuPIQGJJbugXhEeDaeiPPczeJTaaihV0vPzVmk/edit#gid=981567326" target="_blank"><u>ссылку</u></a>.</p> <p>В списке - материалы, полезные для разрабов, аналитиков, менеджеров, бизнес-заказчика и CIO.</p> wangoff:PHdPAAtTSvH2021-08-22T18:53:14.941Z2021-08-22T18:53:14.941Z

<img src="https://static.wixstatic.com/media/137802_e50b798c1f8a4a2cb5f08fcc42812881~mv2.jpg/v1/fill/w_631,h_631,al_c,lg_1,q_90/137802_e50b798c1f8a4a2cb5f08fcc42812881~mv2.webp">Друзья, всем привет! Недавно получил книгу "Настольная книга аналитика. Практическое руководство по проектированию бизнес-процессов и организационной структуры". Хочу поделиться впечатлениями, ведь название - многообещающее, а доступна она только в бумажном варианте на январь 2021 года.

<p>Друзья, всем привет! Недавно получил книгу &quot;Настольная книга аналитика. Практическое руководство по проектированию бизнес-процессов и организационной структуры&quot;. Хочу поделиться впечатлениями, ведь название - многообещающее, а доступна она только в бумажном варианте на январь 2021 года.</p> <p>Ознакомился с книгой и соотнес со своим практическим опытом автоматизации и внедрения ИТ-систем.</p> <h2><strong>Собственно, описание</strong></h2> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_e50b798c1f8a4a2cb5f08fcc42812881~mv2.jpg/v1/fill/w_631,h_631,al_c,lg_1,q_90/137802_e50b798c1f8a4a2cb5f08fcc42812881~mv2.webp" width="631" /> </figure> <p><strong>Вот что написано на <a href="https://consulting.1c.ru/services/analytics-book/" target="_blank">сайте</a> 1С.</strong></p> <p>Фирма «1С» представляет вашему вниманию практическое руководство для специалистов в области управления бизнес-процессами, и прежде всего аналитиков. Книга посвящена построению эффективной и конкурентоспособной организации на основе процессного подхода — совершенствования её бизнес-процессов и организационной структуры.</p> <p>С каждым годом растет потребность в специалистах в области управления бизнес-процессами и, прежде всего, аналитиков. Одно из недавних исследований показало, что бизнес-аналитик — самая востребованная должность в области управления бизнес-процессами.</p> <p>В непрерывно меняющемся мире конкурентоспособность организации в значительной мере определяется и ее возможностью быстро и эффективно реагировать на происходящие перемены. Поэтому постоянное улучшение — один из ключевых принципов любой организации, стремящейся не просто выжить, а успешно осуществлять свою деятельность в долгосрочной перспективе. Потребность в инструментах и методах, способных помочь в решении этих задач, в определенной степени обусловила появление и развитие процессного подхода к управлению. Суть его заключается в выделении в организации бизнес-процессов и управлении ими.</p> <p>И именно бизнес-аналитики играют ключевую роль в постановке процессного подхода в компании. Еще важнее роль бизнес-аналитика при внедрении современных информационных систем. Отчасти рост потребности в бизнес-аналитиках вызван именно все более углубляющейся автоматизацией процессов в российских компаниях. Например, во всех без исключения проектах внедрения прикладных систем на платформе «1С:Предприятие» аналитики партнеров фирмы «1С» совместно с заказчиками оптимизируют и формируют процессы «как надо». Качественная поддержка деятельности информационными системами невозможна без работы бизнес-аналитиков.</p> <p>Однако не до конца понятно, каким объемом знаний и навыков должны обладать специалисты по анализу бизнес-процессов. Существующая литература по данному вопросу посвящена теоретическим аспектам, имеет зачастую непростую форму изложения материала и, главное, не привязана к решению практических задач.</p> <p>Авторы книги решили восполнить этот пробел и создать практическое руководство по построению эффективной и конкурентоспособной организации на основе совершенствования ее бизнес-процессов и организационной структуры. Акцентировать внимание читателя не на том, что такое процессный подход, а на том, как планомерно, шаг за шагом, эффективно применять его на практике. И при этом собрать в одной книге наиболее эффективные и популярные методы и технологии анализа и оптимизации процессов и оргструктуры. Другими словами, это и практическое руководство, и настольная книга бизнес-аналитика.</p> <p>Следует особо отметить, что рассматриваемые в книге технологии и методы:</p> <ul> <li>универсальны и могут применяться при построении любых организаций;</li> <li>являются обобщением многолетнего мирового опыта по совершенствованию деятельности организаций, адаптированного к российскому бизнесу, и абсолютно применимы для российских предприятий;</li> <li>использовались авторами в проектах по совершенствованию деятельности российских компаний, реализованных за более чем 10-летний период работы.</li> </ul> <p>Книга написана просто и ясно, что делает ее доступной для широкого круга аналитиков, как начинающих, так и совершенствующих свои навыки. Стремясь сделать книгу максимально понятной, мы сделали более 200 пояснительных рисунков и диаграмм. Часть графических схем процессов, представленных в книге, разработана с помощью «1С:Системы проектирования прикладных решений», предназначенной для проектирования прикладных решений на платформе «1С:Предприятие».</p> <p>Надеемся, что книга станет полезным и эффективным инструментом для тех аналитиков и специалистов, которые участвуют в проектах оптимизации и автоматизации деятельности организации.</p> <h2>Главы</h2> <p>Глава 1. Классика построения организации</p> <p>Глава 2. Разработка модели организации «как есть». Технология структуризации и описания компании</p> <p>Глава 3. Описание бизнес-процессов</p> <p>Глава 4. Технологии анализа и оптимизации бизнес-процессов. Приоритеты, показатели, типы изменений процессов</p> <p>Глава 5. Методы анализа и оптимизации бизнес-процессов</p> <p>Глава 6. Анализ и оптимизация оргструктуры. Построение горизонтальных взаимодействий</p> <p>Глава 7. Анализ и оптимизация оргструктуры. Построение вертикальных взаимодействий</p> <p>Глава 8. Анализ и оптимизация оргструктуры. Построение взаимоотношений с человеком и внешней средой</p> <p>Глава 9. Регламентация бизнес-процессов и оргструктуры. Контроль и повышение их эффективности</p> <p>Глава 10. Организация работ по оптимизации и описанию бизнес-процессов и оргструктуры для последующей автоматизации</p> <h2><strong>Хорошо</strong></h2> <p><strong>1. Структура </strong></p> <p>По сути, материал действительно претендует на временную «настольность» для тех, кто погружается в тематику анализа и реинжиниринга бизнес-процессов.</p> <p><strong>2. Системность </strong></p> <p>Авторы погружают в тему почти с самого начала и структурированно излагают теорию того, как устроены организации, бизнес-процессы, функции и как распределяется ответственность внутри компании. Далее они приводят неплохую теорию о том, как следует анализировать и улучшать бизнес-процессы. И на десерт – пытаются увязать теорию с задачами автоматизации</p> <p><strong>3. Примеры</strong></p> <p>Обилие оформленных в едином стиле схем, диаграмм. В том числе на основе реальных примеров.</p> <p><strong>4. Ключевые принципы</strong></p> <p>По ходу книги формулируются ключевые принципы. Они просты и оформлены отдельно. Их стоит запомнить</p> <p><strong>5. Логичность </strong></p> <p>Ход мысли авторов последователен. Мысль развивается и раскрывается на примерах. За этим достаточно просто уследить</p> <p><strong>6. Нотации</strong></p> <p>В середине книги дается описание всех используемых сегодня нотаций. Это не учебник по нотациям, но даются рекомендации по использованию. С этого можно начать поиск специализированных материалов</p> <p><strong>7. Термины</strong></p> <p>Что действительно полезно для любых аналитиков и вообще – в книге дается определение всех основных терминов. Бизнес-процессы, функции, ответственность и вот это вот все</p> <p><strong>8. Регламенты</strong></p> <p>Из книги можно понять, что к чему в регламентах, зачем они нужны и почему важно с ними работать</p> <p><strong>9. Вариативность</strong></p> <p>Авторы не диктуют единый курс партии, но описывают варианты для различных методов. Например – вариативность в подходе к описанию бизнес-процессов внутри ИТ-проекта и отдельно. Даются рекомендации</p> <p><strong>10. Корректность суждений</strong></p> <p>Все выводы, рекомендации, принципы – даются достаточно точно, чтобы не быть абстрактными, при этом они не вызвали у меня чувства противоречия при проецировании на реальный опыт</p> <p><strong>11. Актуальность</strong></p> <p>На мой взгляд, в книге рассмотрены все или почти все актуальные формы организации бизнеса. Например, рассмотрен переход к т.н. новой модели бизнеса, при которой процессы становятся проще, а сложность операций сотрудников наоборот, усложняется</p> <h2><strong>Не так хорошо, как я ожидал</strong></h2> <p><strong>1. Ожидания</strong></p> <p>Название книги и ее издатель формируют ожидание, что эту книгу может положить себе на стол аналитик и пользоваться. Это не так. Для системного аналитика, который является основной боевой единицей в проектах автоматизации – эта книга расширит кругозор, но не даст практических рекомендаций. За исключением того, что описано в разделе про «что хорошо»</p> <p><strong>2. Сложность восприятия</strong></p> <p>Когда я читал книгу, у меня за плечами почти 15 лет опыта автоматизации во всех известных ролях. Я освежил знания, кое-где прихватил терминов, наметил точки роста. Но если бы я читал ее в 2010м – для меня 90% книги были бы пустым звуком с красивым звучанием и картинками. Начинающие специалисты не смогут спроецировать информацию на свой практический опыт, им нужны пояснения. А в идеале – практические занятия по разбору каждой главы</p> <p><strong>3. Продакт-плейсмент СППР</strong></p> <p>В конце книге идет бонус-раздел про СППР. И в общем-то это неплохо, кроме СППР нет у вендора годных инструментов. Но вот беда в том, что СППР не является инструментом для анализа и реинжиниринга бизнес-процессов. И, как следствие, все что изложено в книге – имеет мало общего с СПППР. Да, СППР поддерживает IDEF. Но, во-первых, IDEF в СППР применяет от силы 20 команд в стране, а большая часть – для фиксации, но не моделирования или анализа. А во-вторых, проектирование прикладных решений (так расшифровывается СППР) – оно про функционал автоматизируемой системы, что идет после того, что изложено в книге</p> <p><strong>4. Нет данных об инструментах</strong></p> <p>В дополнение к п.3, в книге вообще нет сведений о достойных инструментах проектирования и анализа бизнес-процессов. Я бы хотел увидеть в книге отсылки хотя бы к Visio, Camunda modeler и так далее.</p> <p><strong>5. Не раскрыта тема проектирования ИТ-систем</strong></p> <p>В финальной главе №10 авторы пытаются дать рекомендации о том, как построить работу по моделированию бизнес-процессов. И как раз это, увы, им удалось хуже всего, на мой взгляд. По сути, говоря про связь бизнес-процессов и ИТ-систем, авторы ограничиваются тезисом о том, что ИТ-команда хорошо представляет ограничения целевой системы и должна работать в тесной связи с бизнес-аналитиками. А вот как именно это увязать – не раскрыто. Также не раскрыта важная тема – важность моделирования бизнес-процессов применительно к конкретным системам. В книге даже между строк я не нашел такую рекомендацию</p> <p><strong>6. Речь идет не о тех аналитиках</strong></p> <p>Авторы говорят, что книга предназначена для бизнес-аналитиков. При этом, между строк можно усмотреть отождествление бизнес и системного аналитика. Но на мой взгляд, книга предназначена для аналитиков бизнес-процессов, которые решают лишь подмножество задач бизнес-анализа</p> <p><strong>7. Как увязать бизнес-процессы и требования к ИТ-системе</strong></p> <p>Хочу выделить этот пункт отдельно, хотя он косвенно упоминается в предыдущих. Моя практика показывает, что на ИТ-проектах, особенно там, где не идет речь об автоматизации финансового учета, самая сложная тема – увязать целевую процессную модель предприятия и требования к ИТ-системе. По сути, в этом во многом и состоит задача проектной команды на этапе проектирования. Для этого некоторые пишут объемные ТЗ, некоторые используют СППР. Но боль остается и учить этому аналитиков нужно. И я очень рассчитывал, что я смогу дать эту книгу своим аналитикам и сказать: читай от сих до сих, а потом мы обсудим, как это применять на практике. Увы, на этот вопрос книга ответа на дает. По сути, книга ограничивается на стадии «как описать процессную модель» и даже не говорит, где это стоит делать</p> <p><strong>8. Нет ничего про BPMS</strong></p> <p>Казалось бы, напрашивется тезис о том, что в мире есть такая штука, как BPMS системы и они максимально про бизнес-процессы, их моделирование, анализ, реализацию, мониторинг и улучшение. Но об этом почему-то книга не упоминает. При этом, рекомендует СПППР. Думаю, все дело в том что у вендора нет хорошего BPMS-движка в арсенале. BPMS системы по определению нацелены на решение задач в т.ч. эволюционного развития бизнес-процессов и их мониторинга. Было бы крайне полезно увидеть мнение авторов о том, как методы из книги реализуются современными BPMS. Настоятельно рекомендую изучить аудитории книги вопрос BPMS</p> <p><strong>9. Только бумажная версия</strong></p> <p>Я конечно понимаю, что как только появится электронная версия – есть риск того, что ее спиратят. Но ведь и так – отсканируют и выложат куда надо. Кажется, мир уже научился работать с электронной дистрибуцией. Я был бы первым, кто купил на Play Market’е электронную версию</p> <h2><strong>Целевая аудитория</strong></h2> <p><strong>Аналитики бизнес-процессов </strong>– мастхэв для изучения. Без объяснений.</p> <p><strong>Системные аналитики</strong> – очень сильно рекомендую для того, чтобы понимать, что приходит на вход ИТ-проекта. И чтобы знать, какие нотации могут встречаться.</p> <p><strong>Руководители подразделений</strong> – настоятельно рекомендую для того, чтобы понимать, в какую сторону думать при оптимизации бизнес-процессов. Много полезного про оценку и поиск проблем в процессах.</p> <p><strong>Руководители проектов</strong> – мастхэв. Важно для правильной инициации работ, для понимания правильной работы с регламентами и связи организационных изменений с ОПЭ внедряемых систем</p> <p><strong>Руководители фирм-франчайзи</strong> – настоятельно рекомендую для прочтения. В текущем состоянии, многие партнеры фирмы 1С нуждаются в применении описанных методик организации процессов внутри самих себя.</p> <h2><strong>Выводы</strong></h2> <p>Очень смешанные у меня чувства. Книга мне понравилась. Но она немного не о том, чего ждешь от нее, зная что ее издает 1С и в названии стоит слово «аналитик».</p> <p>Книга, которой не хватало, которая расставит по полочкам вопросы по организации процессов в компаниях. Но не даст ответ на вопросы, связанные с применением методки с использованием современных инструментов и на реальных ИТ-проектах.</p> <p>Полезна скорее бизнесу, чем командам внедрения.</p> <p>Об этой книге можно сказать так. Представьте, что вы заказали в магазине футбольные бутсы. А вам привезли отличный… футбольный свисток. И вот если вы в душе фанат Пьерлуиджи Коллина и хотите попробовать себя в судействе-– заказ окажется полезным. А если вы фанат Артема Дзюбы и его бомбардирских подвигов – тут уж никак, придется разочаровываться. Хотя, в общем-то и то и то – про футбол.</p> wangoff:-4laWMSQpaL2021-08-22T18:52:33.438Z2021-08-22T18:52:33.438Z

<img src="https://static.wixstatic.com/media/137802_70056a95403d4290a5a37541ddac1c9d~mv2.jpg/v1/fill/w_814,h_667,al_c,q_90/137802_70056a95403d4290a5a37541ddac1c9d~mv2.webp">Дизайн – очень сложное понятие. Кто-то понимает под дизайном разработку красивых интерфейсов с привлечением квалифицированных дизайнеров. Кто-то – детальный анализ пользовательского опыта и проектирование интерфейса на его основе. Кто-то – сам факт наличия интерфейса. Что вообще есть дизайн...?

<figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_70056a95403d4290a5a37541ddac1c9d~mv2.jpg/v1/fill/w_814,h_667,al_c,q_90/137802_70056a95403d4290a5a37541ddac1c9d~mv2.webp" width="814" /> </figure> <p>Дизайн – очень сложное понятие. Кто-то понимает под дизайном разработку красивых интерфейсов с привлечением квалифицированных дизайнеров. Кто-то – детальный анализ пользовательского опыта и проектирование интерфейса на его основе. Кто-то – сам факт наличия интерфейса. Что вообще есть дизайн...?</p> <p><a href="https://ux.pub/chto-takoe-dizayn-chetyre-opredeleniya-dizayna/" target="_blank">Вот</a>, например много букв про дизайн на специальном ресурсе:</p> <blockquote><em>Возможно, одна из самых больших сложностей в поиске единого определения дизайна – это широта и разнообразие дизайн-активностей, решаемых проблем и результатов. На самом широком уровне дизайнеры могут быть классифицированы по среде, с которой они работают: физические объекты, цифровые интерфейсы, визуальные системы, окружающие среды, опыт и т. д. Хотя некоторые дизайнеры стремятся быть универсалами и работают над всеми типами дизайна, часть дизайнеров выбирает узкую специализацию. Другие находят подвиды дизайна, которые им нравятся, но могут работать и с остальными. Множество специальностей появилось, чтобы описать профили и аспекты дизайна, с которыми они работают. Это разнообразие может запутать их коллег, не являющихся дизайнерами, особенно в попытках найти подходящего дизайнера для своей команды.</em></blockquote> <p>То, что дизайн, в общем понимании этого слова, в корпоративных системах оставляет желать лучшего – это уже притча во языцех. Все кому не лень, ругают 1С за дизайн. Потом оказывается, что и SAP с Axapta ушли недалеко. И вот легионы пользователей и айтишников ломают копья о том, что доколе вообще.</p> <p>Вот возьмем какой-нибудь типовой продукт «1С:Управление чем-то там». Вендор выпустил типовое решение. Как смог. В решении заложен определенный базис. За решение отвечает вполне определенная команда разработки. И ее можно поругать за то, что дизайн не очень. И, вполне вероятно, есть за что поругать. Но в целом – дизайн 1С вполне себе ничего по сравнению с конкурентами. Иначе продаж не было бы.</p> <p>Но давайте сравним с чем-то действительно «задизайненым». Ну, например, сайт aviasales. Зачем сайту aviasales нужен качественный… да что там.. просто охренительный дизайн? Есть обоснование:</p> <ul> <li>Десятки тысяч пользователей в день</li> <li>Несколько конкурентов – onetwotrip, ozon.travel и тогдалее.</li> <li>Пользователь не читает инструкцию, пользователь идет по интуитивно понятному кейсу</li> <li>Каждый потерянный пользователь – потеря денег. Не куплены билеты, потрачены деньги на контекстную рекламу</li> <li>Посчитать экономический эффект от потери клиентов – возможно. Эффект огромен</li> </ul> <p>А теперь посмотрим на «1С:Управление чем-то там»</p> <ul> <li>Решение о внедрении принято</li> <li>Пользователей – десятки. В лучшем случае – сотни. В особых случаях – несколько тысяч.</li> <li>Система снабжается инструкциями</li> <li>В ходе работ обязательно проводится обучение</li> <li>Работа в системе – должностная обязанность</li> <li>Пользоваться другой системой – невозможно</li> <li>Экономический эффект – умозрительный. В лучшем случае можно посчитать трудозатраты на отражение операций и зафиксировать увеличение на 5-20%</li> <li>Функционал корпоративных решений существенно сложнее, чем юзер-стори по выбору билета. В документах используются сотни реквизитов и взаимосвязей между ними</li> </ul> <p>Отсюда:</p> <ul> <li>Далеко не каждый заказчик не пойдет на увеличение time to market функционала из-за редизайна бантиков</li> <li>Обосновать экономику включения дизайнера в техпроцесс – задача из разряда шаманства</li> <li>Дизайнера на 1С еще пойди найди</li> <li>Компетенции &quot;дизайна&quot; имеет смысл наращивать у системных аналитиков. Хорошо бы воспитывать аналитиков рисовать аккуратные прототипы в мокапе, а разработчиков – аккуратные формы</li> <li>Привлечение, например, UX-дизайнера – резко увеличивает стоимость работ и требует перестроения технологий разработки, включение туда этапа дизайна</li> <li>Нет предела совершенству. Если команда проекта умеет разрабатывать/дорабатывать корпоративную систему так, что она понятна, в ней нет лишних кнопок, противоречивых названий - это уже можно считать неплохим результатом</li> </ul> <p>Если вы зайдете в форму заявки на оплату в любой системе любой корпорации – это будет монстр, порожденный тысячами хотелок и месяцами кросс-функционалных согласований. И, казалось, бы после запуска можно было и переделать, но: а) где взять бюджет? б) проведено обучение и пользователи привыкли в) зачем...?</p> <p>Когда в корпоративных системах случится крутой дизайн? Не уверен, что это в принципе случится. Скорее всего, типовые решения будут постепенно эволюционировать и учитывать новые достижения в области интерфейсов.</p> <p>Дизайн имеет место быть для облачных решений. Таких, как, например, Битрикс, Slack и т.д. То есть, для систем. которые:</p> <ul> <li>Изначально располагаются в облаке</li> <li>Обслуживают сотни и тысячи клиентов, сотни тысяч пользователей</li> <li>Предполагают начало использования сразу после подключения</li> <li>Используют исключительно веб-клиент</li> </ul> wangoff:_CSS0ckjChC2021-08-22T18:52:01.301Z2021-08-22T18:52:01.301Z

<img src="https://static.wixstatic.com/media/137802_5ff5c101bc324c1fbca502e863e92b73~mv2.jpg/v1/fill/w_814,h_457,al_c,q_90/137802_5ff5c101bc324c1fbca502e863e92b73~mv2.webp">Что не так с формальной стороной проектов атоматизации?

<figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_5ff5c101bc324c1fbca502e863e92b73~mv2.jpg/v1/fill/w_814,h_457,al_c,q_90/137802_5ff5c101bc324c1fbca502e863e92b73~mv2.webp" width="814" /> </figure> <p><strong>Что не так с формальной стороной проектов атоматизации?</strong></p> <p>Проект автоматизации – это не только лишь работающая система, но и подписанные проектные документы. И акты. Каждый первый проект автоматизации предполагает работы по подготовке и согласованию проектных документов. Состав и названия разные, но по сути можно обобщить их под кодовым словом «Техническое задание». Как правило, техническое задание должно быть согласовано до начала работ по разработке и настройке.</p> <p>Чем сложнее проект, крупнее заказчик и разнообразнее состав проектных документов, тем больше времени уходит на согласование. На крупных корпоративных проектах заставить бизнес подписаться под чем-то – задача из области искусства.</p> <p>Как правило, если исполнитель ответственно подходит к проектированию и действительно пытается сперва согласовать ТЗ, проект через квартал-полгода-год приходит к состоянию «ничего не сделано, пишутся бумажки». При грамотном администрировании, ответственность за длительное проектирование частично может быть разделена с заказчиком, но кому от этого легче, если проект не двигается?</p> <p>Некоторые исполнители задаются вопросом «что делать с ТЗ, которое никак не напишется и не согласуется» спустя полгода, некоторые, набившие шишки, задаются таким вопросом сразу. Все возможные варианты действий можно разделить на две стратегии</p> <ul> <li>Согласовать, нельзя программировать - Нет уж, мы должны сперва все согласовать</li> <li>Согласовать нельзя, программировать - Давайте поделаем систему, а потом как-то договоримся и подпишем бумажки</li> </ul> <p>Как ни странно, обе стратегии, по разным причинам, но одинаково часто приводят к неуспеху.</p> <p><strong>Согласовать, нельзя программировать</strong></p> <p>Причины неуспеха в этой стратегии обычно такие:</p> <ul> <li>Заказчик психанул и выгнал за отсутствие результатов</li> <li>Очень долго согласовывали и согласовали ТЗ. За это время изменились требования и состав проектной команды у заказчика</li> <li>Напроектировали то, что на деле невозможно автоматизировать</li> <li>Согласовали очень поверхностное ТЗ, в ходе реализации скоуп проекта вырос, сроки уехали</li> </ul> <p><strong>Согласовать нельзя, программировать</strong></p> <p>Причины неуспеха в этой стратегии обычно такие:</p> <ul> <li>Бесконечные изменения требований, апеллировать к согласованной постановке невозможно. Сроки уехали, бюджет кончился</li> <li>Начали делать без проработки концепции, в ходе реализации выяснилось, что нужно было делать принципиально иначе. Нужно все переделывать. Сроки уехали, бюджет кончился.</li> <li>Менеджера проекта от исполнителя выгнали за отсутствие подписанных актов по проекту</li> <li>За отсутствием ТЗ, заказчик не понимает всю сложность проекта, а конкурент рассказывает на конференциях что задача плевая. В итоге – заказчик психанул и закрыл проект</li> </ul> <p><strong>Что делать?11 «как» повысить вероятность успеха проекта автоматизации</strong></p> <p>Может показаться, что делать проекты – дело неблагодарное и лучше этим не заниматься. И вот что я скажу – это действительно во многом истинное утверждение. Рисков много, я знаю достаточно примеров, когда компании переключались на другие виды деятельности.</p> <p>Но все же, многие пытаются. А бизнес-заказчику в принципе не уйти от задач автоматизции. Какие можно дать советы для этих компаний и людей?</p> <p><strong>1. Не работайте с мудаками.</strong></p> <p>Работает в обе стороны. Если заказчик не договороспособен – не питайте иллюзий что он закроет проект, когда система начнет работать. Если исполнитель – это набор фиксиков, которые вчера узнали что такое ТЗ и проектная работа – не питайте иллюзий что они сделают проект вовремя и как следует.</p> <p><strong>2. Проверяйте гипотезу об адекватности участников проекта</strong></p> <p>Работает в обе стороны. Если можно сначала зайти не в большой проект, а в мелкий – сделайте это. Подпишитесь на обследование вместо комплексного проекта внедрения. На этом микропроекте стороны посмотрят друг на друга. Если уже запущен крупный проект – попробуйте пройти все стадии проектирования-согласования-внедрения на как можно более мелкой задаче. На ней вы узнаете, насколько исполнитель в состоянии достигать результат, а заказчик – участвовать в проектировании и приемке результатов.</p> <p><strong>3. Определите конъюнктуру проекта. Формальность или результат?</strong></p> <p>В некоторых компаниях важнее получить формальные артефакты, чем результат. К счастью, так происходит не везде. Но проверить эту гипотезу лучше в самом начале. Понимание приоритета заказчика позволит более осознанно подходить к принятию решения о входе в проект, а также к постановке целей проектной команды.</p> <p>Учтите, что договоры на проект автоматизации, заключенные по 223ФЗ или 44ФЗ - допускают очень узкое пространство для маневра в части формальных артефактов проекта.</p> <p><strong>4. Стартуйте как можно раньше</strong></p> <p>Если есть возможность – бейте проект на этапы, на которых система запускается в ОЭ/ОПЭ/ПЭ как можно раньше. Это не только позволит закрывать работы поэтапно, но и позволит снизить риски «не той системы». Как только пользователи начинают работать с системой – вы сразу же узнаете, что они думаю о ней. И сможете скорректировать требования на последующих этапах работ. В рамках такого подхода часто используют термин MVP – минимальный жизнеспособный продукт.</p> <p><strong>5. Моделируйте</strong></p> <p>Проектировать в ворде – хорошо. Но лучше – проектировать наглядно. Особенно, если внедрение осуществляется на базе существующего «типового» продукта. Когда бизнес увидит, как будет выглядеть будущая система – он точнее сформулирует требования, ему проще объяснить нереальность части требований, он быстрее согласует ТЗ. Для моделирования может применяться как сама система, так и другие инструменты – Excel, инструменты для создания мокапов экранных форм.</p> <p><strong>6. Не отказывайтесь от согласования</strong></p> <p>Помните, что в курсе всех сложностей проекта – только проектная команда. У топ-менеджмента с обеих сторон таких проектов – несколько, а то и десятки. Топ-менеджмент управляет на макро-уровне и смотрит артефакты. Если не удается согласовать подробное ТЗ – договоритесь на уровне проекта о том, чтобы согласовать концепцию. И уже она будет задавать границы ТЗ в будущем. Не удается согласовать никакие документы – согласуйте прототип, подпишите протокол о том, что прототип годится. Это не снимет всех вопросов, но часть – уберет.</p> <p><strong>7. Эскалируйте невозможность согласования</strong></p> <p>Очень часто исполнителя ставят в положение «вы ничего не умеете, потому херачьте так, а мы потом посмотрим что с вами делать». Такое положение ни разу еще не приводило к успешному закрытию проекта. Если исполнитель действительно не очень – зачем ждать, пока он потратит год жизни компании и уйдет ни с чем и со скандалом? Если же команда исполнителя может решать задачи создания системы – менеджер проекта должен бить в набат и кричать во всю мощь о том, что проект скоро войдет в штопор, это его прямая задача. Как правило, истина где-то посередине – исполнитель не смог донести внятно свои идеи, а заказчик не посчитал возможным вникнуть. Такая проблема решается на уровне проектного менеджмента и изменения подходов к проектированию. Чем дольше эту проблему не решают – тем дороже обходится обслуживание такого проекта, и рано или поздно приводит либо к прекращению проекта, либо к серьезному и глубокому разговору. Иногда такой разговор называют «ретроспектива проекта».</p> <p><strong>8. Не путайте согласование и документирование</strong></p> <p>Никогда. Слышите, никогда! Не отказывайтесь от документирования того, что происходит на проекте. Даже если не удается согласовать проект. Нужно помнить, что даже если сложилась такая страшная ситуация, что исполнитель выполнил много работы без согласования – нужно хотя бы знать, что сам исполнитель понимает и верит в то, что делает. А без документирования:</p> <ul> <li>Невозможно воспроизвести состав и содержание работ, которые сделаны на проекте</li> <li>Растет технический долг</li> <li>Создается множество несогласованного функционала</li> <li>Невозможно написать инструкцию к тому что сделано</li> <li>Очень долго и дорого онбордить новых людей на проект</li> <li>Команда проекта тонет в бесконечных переделках и хаосе</li> <li>Всегда есть риск того, что сделано не то что нужно</li> </ul> <p><strong>9. Развивайте системы управления требованиями и задачами</strong></p> <p>Jira, Redmine, Trello, СППР и множество других систем – это мастхэв при работе на ИТ-проектах. Вся работа по управлению требованиями должна быть построена на базе хоть какой-то системы управления этими требованиями. В конечном счете, на базе этих требований можно составить word-документ и назвать его «ТЗ». MVP такой системы:</p> <ul> <li>Трекинг статуса задач</li> <li>Хранение постановок требований и вложений</li> <li>Регламент по работе с требованиями для бизнеса, аналитиков, разработчиков</li> <li><em>В т.ч. пункт про хранение всех договоренностей по задачам в системе</em></li> </ul> <p>Просто примите как факт, что на проекте, который делается не «в одного», управлять содержанием работ только на базе вордовых и эксельных файлов – устаревшая технология, которая не имеет права на жизнь.</p> <p><strong>10. Управляйте проектом</strong></p> <p>Проект должен всегда иметь руководителя проекта с компетенциями именно управления проектом. Особенно для проектов на 1С, характерно назначать руководителем проекта самого талантливого аналитика или программиста. Что зачастую приводит к отсутствию управления. Иногда роль менеджера проекта совмещается с менеджером продукта, что не противоречит. MVP менеджера проекта:</p> <ul> <li>Умеет ставить команде проекта задачи по SMART</li> <li>Умеет предоставлять внятную информацию о статусе проекта, в т.ч. о плане работ, методах реагирования на риски</li> <li>Умеет администрировать задачи</li> <li>Умеет вести переговоры, аргументировать позицию</li> <li>Умеет строить план работ, ресурсный план</li> <li>Умеет готовить презентации</li> <li>Умеет работать с договорными отношениями</li> </ul> <p><strong>11. Создавайте технологию автоматизации</strong></p> <p>С одной стороны – у вас есть множество готовых методик управления проектами по Scrum, PMBok, PRINCE, Kanban, ТКВ, ТБР и так далее.</p> <p>С другой стороны – у вас есть специфичный набор технологий, на базе которых происходит автоматизация. У бизнеса этот набор продиктован ИТ-ландшафтом. У исполнителя этот набор продиктован спецификой проектов, в которых он силен.</p> <p>Как компании-заказчику, так и компании-исполнителю следует выработать и постоянно улучшать технологию ведения проектов. На стыке двух технологий, имея возможность сопоставить технологии заказчика и исполнителя, можно выработать жизнеспособную стратегию автоматизации на конкретном проекте с конкретными участниками.</p> <p><strong>Выводы</strong></p> <p>Значительная часть проектов -проваливается. Как правило, это заслуга всех участников.</p> <p>Успех автоматизации зависит:</p> <ul> <li>от зрелости заказчика</li> <li>от его желания выполнить проект и способности принимать быстрые решения</li> <li>от наличия отработанных технологий внедрения с обеих сторон</li> <li>от наличия грамотного администрирования проекта</li> <li>от наличия удобных инструментов для управления содержанием системы.</li> </ul> <p>Для успеха в таком предприятии все участники проектной команды должны быть ориентированы на результат и находить баланс между формальной и содержательной составляющей проекта.</p> wangoff:Z8yyJT5G8-K2021-08-22T18:51:20.689Z2021-08-22T18:51:20.689Z

<img src="https://static.wixstatic.com/media/137802_2f914043159148a38c6fdd53e8b18943~mv2.jpg/v1/fill/w_793,h_758,al_c,q_90/137802_2f914043159148a38c6fdd53e8b18943~mv2.webp">Эта статья - о том, как устроен рынок услуг, который называется «доработка и внедрение 1С». Здесь описывается базовая расстановка сил на рынке 1С и к данному тексту я буду апеллировать в последующих публикациях.

<p>Эта статья - о том, как устроен рынок услуг, который называется «доработка и внедрение 1С». Здесь описывается базовая расстановка сил на рынке 1С и к данному тексту я буду апеллировать в последующих публикациях.</p> <h2><strong>Историческая справка</strong></h2> <p>Фирма 1С заняла доминирующую позицию на рынке автоматизации малого и среднего бизнеса в первую очередь благодаря сети партнеров. В свое время братья Нуралиевы выбрали (или придумали применительно к ИТ?) путь развития партнерской сети по схеме франчайзинга.</p> <p>Фирма 1С как вендор – не зарабатывала и не зарабатывает на проектах внедрения. Основные источники дохода:</p> <ul> <li>продажа продуктов,</li> <li>продажа лицензий,</li> <li>сервис информационно-технического сопровождения (раньше это были диски),</li> <li>дистрибуция софта.</li> </ul> <p>Иными словами, вендор не оказывал никаких услуг по настройке, доработке, сопровождению и поддержке информационных систем, которые разрабатывал.</p> <p>Задача вендора – выпустить продукт. Задача франчайзи – продать продукт бизнесу и решить задачу «последней мили» в виде установки, доработки, поддержки.</p> <p>При этом, были заданы единые правила игры для всех франчайзи во всех городах и странах присутствия:</p> <ul> <li>Цены на продукты едины для всех. Нельзя продать продукт по цене, ниже указанной. С учетом посредников, разница между стоимостью закупки и продажи для франчайзи составляет 40-50%</li> <li>Все франчайзи должны выполнять нормативы по продаже сервиса ИТС</li> <li>Для всех партнеров организована площадка для обмена мнениями, жалобами, проблемами в виде единого партнерского семинара, который проводился два раза в год и на который приглашались только сотрудники франчайзи</li> <li>Программный код всех продуктов был открытым</li> </ul> <p>За счет такой стратегии развития, продукты 1С быстро распространились по всей стране. За счет простоты доработки, франчайзи росли как на дрожжах. По этой же причине встала проблема пиратства.</p> <p>Изначально, было три основных продукта, которые позволяли автоматизировать бухгалтерский учет, торговые операции, расчет зарплаты.</p> <p>Постепенно масштаб задач рос, продукты фирмы 1С научились решать очень широкий спектр задач автоматизации бэкофисных операций, включая задачи автоматизации производства. В задачи франчайзи теперь входила не только локальная разработка, но и задачи консалтинга, использование проектных технологий.</p> <p>1С &quot;подружилась&quot; с консалтинговыми компаниями из «Big4» и обеспечила поддержку продвижения продуктов на средний и крупный бизнес.</p> <p>Со временем, масштаб задач рос, на горизонте возникла конкуренция с крупными игроками – SAP, Microsoft, Oracle.</p> <p>Постепенно, крупные интеграторы и консалтинговые компании начали открывать у себя отдельные направления по автоматизации на фреймворке «Платформа 1С». Включая КРОК, IBS, EY, PwC и других.</p> <p>Руководитель 1С, Борис Георгиевич Нуралиев, к этому времени активно ̶л̶о̶б̶б̶и̶р̶о̶в̶а̶л̶ представлял интересы ИТ-отрасли в целом и 1С, в частности, на уровне государственных комиссий, в которые он входит и сейчас.</p> <h2><strong>Обстановка на 2020 год</strong></h2> <p>На сегодняшний день фирма 1С выпускает/лицензирует в совокупности более 450 сертифицированных продуктов. Помимо этого, разработано большое количество универсальных модулей и сервисов. Подобные модули (пример: БСП, БПО) и сервисы (пример: 1С:Номенклатура) интегрируются в существующие и в разрабатываемые с нуля продукты, а также используются для управления разработкой (пример: СППР)</p> <p><strong>Участники рынка</strong></p> <p>Несмотря на рост вариативности задач и услуг, партнерская сеть 1С на сегодня сохраняется и действует по заложенным изначально принципам. Для партнеров увеличилось количество «медалей», которые призваны помочь клиентам выбрать наиболее компетентного в их задаче партнера. Работает ли это как следует? На мой взгляд – нет.</p> <p>На сегодня, по официальной информации на сайте, у фирмы 1С более 7000 сертифицированных партнеров.</p> <p><strong>Франчайзи</strong></p> <p>Среди партнеров существует разделение по направлениям деятельности:</p> <ul> <li>Поддержка типовых продуктов и продажа информационных сервисов</li> <li>Экспертиза в узких нишах (закупки, лизинг, бюджетирование и т.д.)</li> <li>Крупные корпоративные проекты внедрения</li> <li>Поддержка малого бизнеса</li> <li>Разработка решений с нуля</li> <li>Продажа и внедрение собственных продуктов на 1С (например, 1С:БИТ)</li> <li>Аутсорсинг программистов другим франчайзи и бизнес-заказчикам</li> </ul> <p>При этом, нет четких ограничений и франчайзи могут взяться за работу по не приоритетному для себя направлению. Например, наряду с крупными проектами, франчайзи может оказывать поддержку типовых продуктов и продавать сервис ИТС, при этом сдать в аренду программиста другому франчайзи.</p> <p>Методики работы франчайзи не регламентируются, но рекомендуются вендором. Для проектной деятельности существует набор рекомендаций по ведению &quot;обычных&quot; и корпоративных проектов. Методики называются ТБР - технология быстрого результата и ТКВ - технология корпоративного внедрения.</p> <p>Все, или почти все, франчайзи относятся к малому и среднему бизнесу. Очень субъективно можно определить величину франчайзи так:</p> <ul> <li>Микроскопические - штат до 10 человек</li> <li>Маленькие - штат до 30 человек</li> <li>Средние - штат от 30 до 100 человек</li> <li>Крупные - штат от 100 человек и выше.</li> </ul> <p>Из такой градации можно сделать вывод, что на проектах для среднего и крупного бизнеса заказчик заведомо превышает по размерам исполнителя, что может стать значимым фактором на проекте. Например, при проведении переговоров, особенно в кризисных ситуациях.</p> <p><em>Я встречал проекты, бюджет которых можно было бы направить на покупку франчайзи, штат которого был равен команде проекта.</em></p> <p>Полный список франчайзи приводится на сайте 1С. Для поиска из числа всех партнеров можно перейти с<a href="https://1c.ru/rus/partners/franch-citylist.jsp" target="_blank">юда</a>.</p> <p>Простой поиск по региону выдает 680 фирм-франчайзи на территории города Москва. При этом, явным образом выделяется:</p> <ul> <li>Сертифицированы ли процессы партнера по стандарту ISO – признак качества организации процессов внутри франчайзи</li> <li>Есть ли у партнера статус «Реальная автоматизация» - этот статус обычно дают партнерам, которые отчитались о большом количестве успешных проектов внедрения</li> <li>Есть ли у партнера статус «Эксперт по маркировке» - вероятно, это связано с актуальностью запроса на задачи по маркировке</li> </ul> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_2f914043159148a38c6fdd53e8b18943~mv2.jpg/v1/fill/w_793,h_758,al_c,q_90/137802_2f914043159148a38c6fdd53e8b18943~mv2.webp" width="793" /> </figure> <p><strong>Центр компетенции 1С:КОРП</strong></p> <p>Как я писал выше, партнерам 1С может быть выдан широкий список статусов, которые указывают на наличие компетенций в той или иной сфере.</p> <p>Несколько лет развивается сайт 1С:Консалтинг. На нем зарегистрированы те партнеры из общего числа, которые имеют статусы таких центров компетенций. Про каждый из статусов можно узнать подробнее на официальном сайте 1С, но общая идея проста – наличие конкретного статуса снижает риски неуспеха при выборе конкретного партнера для конкретных задач. Продажа некоторых продуктов вендора невозможна без наличия соответствующего отраслевого статуса.</p> <p>Всего на сайте представлена информация о 160 таких партнерах. Про каждого из партнеров можно почитать подробно и ознакомиться с зарегистрированными ими проектами. Каждый партнер регистрирует выполненные проекты на этом же сайте, а затем они могут участвовать в конкурсе Проект года по версии 1С.</p> <p>Список партнеров, которые участвуют в рейтинге по центрам компетенций можно найти <a href="https://consulting.1c.ru/partners/?base=corp&industry=0&country=0&city=0&area=0&search=" target="_blank">здесь</a>. Можно поискать по отраслевому опыту, статусам и еще ряду критериев.</p> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_3a205282b9f3412d94e9b25eaa2489c6~mv2.jpg/v1/fill/w_760,h_712,al_c,q_90/137802_3a205282b9f3412d94e9b25eaa2489c6~mv2.webp" width="760" /> </figure> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_95a48c44c33a4943845de3a883172f7d~mv2.jpg/v1/fill/w_764,h_581,al_c,q_90/137802_95a48c44c33a4943845de3a883172f7d~mv2.webp" width="764" /> </figure> <p><strong>Консалтинговые компании</strong></p> <p>Помимо своих партнеров-франчайзи, на сайте проекта 1С:Консалтинг также приводится информация о консалтинговых компаниях, с которыми 1С ведет сотрудничество. Пока что приведено всего три таких компании, хотя консалтинговых компаний в России значительно больше. С<a href="https://consulting.1c.ru/partners/consult-companies/" target="_blank">писок</a>.</p> <p>Данный раздел для меня - самый загадочный, потому что не до конца прослеживается логика рассуждения потенциального заказчика, который видит на сайте вендора список консалтеров. Обычно работает наоборот.</p> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_51604d9f63ff4931a7fb05862d4a6f2c~mv2.jpg/v1/fill/w_814,h_467,al_c,q_90/137802_51604d9f63ff4931a7fb05862d4a6f2c~mv2.webp" width="814" /> </figure> <p><strong>Интеграторы</strong></p> <p>Помимо франчайзи 1С, услуги консалтинга и заказной разработки с использованием продуктов 1С оказывают интеграторы. Их перечень на сайте 1С не обнаружен, это все или почти все интеграторы. В своей практике чаще всего сталкиваюсь с КРОК, IBS, Columbus IT, Техносерв, Сбертех.</p> <p>В этом же разделе стоит упомянуть консалтинговые компании, потому что они, как правило, выступают в аналогичной роли на проектах аналогичного масштаба. Такие, как EY, PwC, KPMG, Deloitte (о них слышу реже).</p> <p><strong>Внутренние подразделения</strong></p> <p>У многих заказчиков в рамках департамента ИТ нередко сформированы команды, которые:</p> <ul> <li>Поддерживают внедренные системы</li> <li>Реализуют новые проекты автоматизации</li> <li>Управляют командами привлеченных исполнителей</li> </ul> <p>Некоторые такие подразделения выделены в отдельную юридическую структуру и являются партнерами фирмы 1С, что позволяет экономить на закупке продуктов и лицензий, а также дает доступ к информации, доступной только партнерам 1С (например, они могут участвовать в партнерских семинарах)</p> <h2><strong>Основные сценарии реализации проектов </strong></h2> <p>Услуги на рынке 1С шире, чем только заказная разработка. Но здесь я хочу поговорить о рынке внедрения продуктов на платформе 1С и о том, какие основные сценарии выполнения проектов такого рода существуют. Описанные ниже сценарии дополняют и пересекаются друг с другом в реальной жизни.</p> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_9dd95157611646e59a609b893db720bf~mv2.jpg/v1/fill/w_814,h_563,al_c,q_90/137802_9dd95157611646e59a609b893db720bf~mv2.webp" width="814" /> </figure> <p><strong>Реализация силами ДИТ</strong></p> <p>Здесь и далее, я буду использовать термины «ДИТ», «Проектный офис» и другие как некоторое обобщение. В разных компаниях эту роль могут выполнять разные подразделения, люди, в разном составе и разной степенью ответственности.</p> <p>ДИТ – может быть представлен отдельной структурой - &quot;департамент ИТ&quot;, так и отдельно взятым программистом 1С в штате. Основное в данном сценарии – то, что разработку, настройку и запуск функционала осуществляют люди, находящиеся в штате самой компании. Роли программиста, аналитика, консультанта, менеджера проекта распределяются между сотрудниками компании.</p> <p>Распространенные сценарии:</p> <ul> <li>Доработка типовой бухгалтерии силами штатного программиста</li> <li>Передача внедренной системы на сопровождение сотрудникам ДИТ.</li> </ul> <p><strong>Привлечение команды под проект</strong></p> <p>По сути, это то же самое, что реализация своими силами. В штат компании привлекается один человек или целая команда, на ограниченное время. Задача вновь прибывших – реализовать конкретную задачу и покинуть компанию, передав поддержку другим людям. Сложность такого сценария – где взять такую команду. Я знаю истории, когда специалисты, работающие в франчайзи 1С входили в состав таких команд, а на основном месте работы оформляли неоплачиваемый отпуск на полгода. Также есть примеры команд, которые переходят с проекта на проект.</p> <p><strong>Фрилансеры</strong></p> <p>Основа данного сценария: по рекомендации или на сайте фриланса находятся специалисты, которые оказывают услуги заказчику. Сценарий применяется как для малого бизнеса, так и для крупных проектов, куда привлекают экспертов на индивидуальной основе. Фрилансеры стоят для заказчика обычно дешевле чем услуги франчайзи, но всегда есть риск того, что человек пропадет, окажется некомпетентным.</p> <p>По условиям лицензионного соглашения на продукты 1С, услуги по доработке и настройке ПО могут оказывать только сертифицированные партнеры. Привлекая на проект фрилансера, лучше убедиться в том, что на его имя выдан действующий сертификат по платформе 1С:Предприятие или продукту, который предполагается внедрять.</p> <p><strong>Единственный подрядчик</strong></p> <p>Единственным подрядчиком может быть фрилансер, франчайзи, интегратор, консалтинговая компания. Основная особенность - работы по внедрению системы выполняются единственным партнером. Самый распространенный случай - с франчайзи 1С заключается договор на внедрение системы &quot;под ключ&quot;.</p> <p>Нередко, одну компанию обслуживает несколько франчайзи, которые контрактуются и решают задачи независимо друг от друга.</p> <p><strong>Генеральный подрядчик + субподрядчики</strong></p> <p>Такая схема применяется в случаях, когда предполагается:</p> <ul> <li>Запуск нескольких (портфеля или даже программы) проектов для достижения целей бизнеса</li> <li>Предполагается внедрение нескольких систем/модулей, которые потребуют различной предметной экспертизы</li> <li>Предполагается решать разнородные задачи. Например: сначала необходимо выполнить работы по описанию бизнес-процессов, которые впоследствии должны быть автоматизированы с помощью одной или нескольких информационных систем</li> </ul> <p>Основная задача при таком сценарии – координация деятельности нескольких команд. Для реализации такой схемы может быть:</p> <ul> <li>Привлечен проектный офис, который выступает генеральным подрядчиком и обеспечивает координацию всех команд</li> <li>Привлечен интегратор или крупный франчайзи, который привлекает субподрядчиков и обеспечивает координацию всех команд</li> <li>Привлечен проектный офис, который обеспечивает координацию работ с генеральным подрядчиком в лице интегратора/франчайзи/консалтинговой компании</li> <li>Привлечена консалтинговая компания, которая решает часть задач в части консалтинга и привлекает подрядчиков из числа интеграторов и франчайзи</li> </ul> <p>В зависимости от способа реализации, договоры с субподрядчиками заключает либо проектный офис, либо выбранный генеральный подрядчик.</p> <p><em>Несколько лет назад фирма 1С организовала собственную структуру НПЦ 1С, которая привлекается на проекты по схеме генерального подряда. Данная структура выполняет функции генерального подрядчика, выделена в отдельную компанию и, де-факто, выполняет роль интегратора. Преимущества привлечения НПЦ 1С в том, что она обеспечивает более тесную связь с непосредственно фирмой 1С. В структуре компании выделены аккаунт-менеджеры, которые участвуют в пресейлах от лица 1С. Привлекается для таких крупных внедрений, как Ростех, Почта России, Росатом и другие корпоративные гиганты. </em></p> <p><strong>С участием проектного офиса</strong></p> <p>Проектный офис может быть:</p> <ul> <li>В лице единственного сотрудника, назначенного для координации работ. Иногда это представители бизнес-заказчика, но чаще – это отдельная позиция в компании</li> <li>В лице подразделения, подчиненного ДИТ, бизнес-подразделению или иному подразделению</li> <li>В лице подразделения, выделенного в отдельную структуру</li> <li>В лице отдельного юр.лица</li> </ul> <p>Задача проектного офиса – осуществлять координацию работ. Как правило, проектный офис обладает компетенциями проектного менеджмента и имеет собственные регламенты реализации проектов, которым подчиняется работа внутренних и внешних исполнителей.</p> <p>В задачу координации работ также могут и должны входить задачи координации планов по реализации бизнес-инициатив.</p> <p><strong>Без участия проектного офиса</strong></p> <p>Сценарий без привлечения проектного офиса характерен тем, что на бизнес-заказчика возлагается ответственность за координацию работ и за итоговый результат. В таком сценарии основная проблема - ответственный сотрудник может не обладать достаточными компетенциями в части реализации ИТ-проектов, что приводит к росту объема работ, некорректному определению целей и задач проектов, недостаточно точным требованиям и росту напряженности во взаимоотношениях к исполнителю (внешнему или внутреннему)</p> <p><strong>Без участия вендора</strong></p> <p>При таком сценарии, вендор только продает продукт и лицензии. Никак не участвует в реализации проекта. Таких проектов большинство.</p> <p><strong>Привлечение вендора на пилот</strong></p> <p>Когда бизнес планирует запускать проект, который интересен вендору с точки зрения развития функционала внедряемого продукта, может быть запущен «пилотный проект». Чаще всего пилотные проекты запускаются для внедрения новых типовых продуктов, либо для внедрения новой функциональности, которая отсутствует в текущей версии типового продукта.</p> <p>В таком случае сотрудники 1С, которые отвечают за разработку типового решения, привлекаются для консультаций и разбора сложных случаев в ходе проекта. Это позволяет снизить риски заказчику и улучшить функциональность типового продукта вендору.</p> <p>Например, в 2019 году стартовало несколько пилотных проектов по внедрению продукта ERP.Управление холдингом.</p> <p>Пилотный проект может быть совмещен с авторским надзором от вендора.</p> <p><strong>Привлечение вендора для авторского надзора</strong></p> <p>Сценарий предполагает привлечение вендора для осуществления авторского надзора в ходе проекта. Сотрудники фирмы 1С осуществляют мониторинг проекта и помогают разбираться со сложными ситуациями по ходу всего жизненного цикла проекта. Это позволяет снизить риски неправильного использования типового функционала и некачественного управления проектом со стороны непосредственного исполнителя.</p> <p>Данная услуга предоставляется вендором на платной основе и составляет, как правило, около 10% от стоимости проекта. Примеяется на крупных проектах.</p> <h2><strong>Выводы</strong></h2> <p>Рынок услуг «1С» - очень широк и разнообразен. На нем огромное количество игроков. Схемы работы с игроками на этом рынке разнообразны. Значительная часть ошибок, приводящих к провалу проектов или, как минимум, к неоправданному и неизбежному росту расходов на автоматизацию, совершается на этапе планирования проекта. То есть, в том числе, на этапе определения схемы взаимодействия подрядчиками.</p> <p><strong>Как избежать ошибок?</strong></p> <ol> <li>Прочитать эту статью</li> <li>Помнить, что самые главные ошибки осуществляются на самом старте</li> <li>Понять и принять, что нет «серебряной пули» в виде единственно верной стратегии внедрения для любой организации. Оптимальный выбор стратегии базируется на предполагаемом объеме изменений (операций, процессов, культуры) и масштабе организации</li> <li>Принять тот факт, что заключить договор с <u>любым </u>подрядчиком «под ключ» - это еще не гарантия успеха</li> <li>Привлекать профессионалов для качественной экспертизы и оценки предстоящих работ</li> <li>Ставить четкие и достижимые цели автоматизации. Есть слона по частям.</li> <li>Бонусом ко всему вышеизложенному - вы можете <a href="https://www.russianautomatization.com/expertise-in-it" target="_blank"><u>спросить </u></a>у меня.</li> </ol> wangoff:s7SrUAIzPmN2021-08-22T18:50:20.200Z2021-08-22T18:50:20.200Z

<img src="https://static.wixstatic.com/media/137802_b9f077354a2e47dd8bc8222c2393795f~mv2.jpg/v1/fill/w_714,h_328,al_c,lg_1,q_90/137802_b9f077354a2e47dd8bc8222c2393795f~mv2.webp">Очерк о том, как я искал людей к себе в команду. Немного подробностей и пара инструментов. Пишу для себя, чтобы в будущем смотреть прогресс. А также рекомендую всем, кто занимается подбором - чужой опыт лишним не будет.

<p>Очерк о том, как я искал людей к себе в команду. Немного подробностей и пара инструментов. Пишу для себя, чтобы в будущем смотреть прогресс. А также рекомендую всем, кто занимается подбором - чужой опыт лишним не будет.</p> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_b9f077354a2e47dd8bc8222c2393795f~mv2.jpg/v1/fill/w_714,h_328,al_c,lg_1,q_90/137802_b9f077354a2e47dd8bc8222c2393795f~mv2.webp" width="714" /> </figure> <p>Решил немного структурировать свой опыт подбора персонала на свои проекты. Начну с того, что последние лет эдак шесть моя основная задача – работая в компании-подрядчике, выполнить договорные обязательства перед заказчиком. Обязательства заключаются в наличии договора на внедрение корпоративной информационной системы на платформе 1С, а для простоты – проекта. Отягчающие обстоятельства: у проекта есть сроки и бюджет. Проектов одновременно может быть несколько, с разными заказчиками и задачами – это можно назвать портфелем проектов. Получается, что для некоторых проектов я был в роли их руководителя, для некоторых, попроще – в роли куратора и руководителя отдела. В обоих случаях, инициация проекта, включая формирование команды ложилась на мои плечи. Для простоты буду называть себя во всех случаях РП.</p> <p>Немного бэкграунда для людей, которые не сталкивались с задачей инициации проекта:</p> <ol> <li>В корпоративных проектах 1С чаще всего задача подбора ресурсов ложится на плечи РП</li> <li>Правила игры на проекте зачастую определяются не столько компанией, сколько конкретным РП внутри компании. Два проекта в одной компании могут быть выполнены по совершенно разным методикам</li> <li>Компании заинтересованы в максимальной утилизации людей на проект, поэтому в большинстве случаев просто так взять и выделить на проект специалиста – задача не простая, а выделить трех специалистов за 2 недели – кажется почти нерешаемой</li> <li>Команда среднестатистического корпоративного проекта в 1С – это от 5 до 10 человек. Так не всегда, но чаще всего</li> <li>В разных компаниях ролевая модель разная. Все сильно по разному и зависит от масштаба, сложности, роли заказчика в проекте и много чего еще. Но постепенно рынок приходит к тому, что основные роли на внутри команды проекта обязательно должны включать такие пункты:</li> <li>Функциональный архитектор</li> <li>Технический архитектор</li> <li>Аналитики (могут быть разного уровня)</li> <li>Разработчики (могут быть разного уровня)</li> <li>Почти в каждой компании есть HR. Почти везде функции HR сводятся к:</li> <li>Подбору и обзвону резюме на hh.ru</li> <li>Приглашению на интервью и проведении первой встречи, на которой отсеиваются точно не подходящие кандидаты</li> <li>В оформлении новых сотрудников</li> <li>Зачастую поиск людей на позиции архитекторов и аналитиков на внешнем рынке – задача с неизвестным сроком и результатом, который может превышать один и даже два месяца</li> <li>Поиск разработчиков сводится зачастую к обзвону подходящих кандидатов, приглашению на собеседование и решение ими тестовых задач. Тестовые задачи проверяются техлидом</li> <li>Как правило, у РП нет каких-то особых знаний про маркетинг или HR, потому процесс подбора кандидатов происходит исходя из общих представлений о прекрасном конкретного человека, который столкнулся с задачей</li> </ol> <p>Теперь, когда бэкграунд известен, расскажу немного кейсов о том, как мы искали людей на проекты. Как вы уже поняли, особых диполов о поиске персонала у меня нет. Как и времени на поиск людей никто не дает. Нужно вчера, к тому же еще и найти время в жестоком графике.</p> <h2><strong>Стажеры</strong></h2> <p>Текущий рынок таков, что обеспечить 3 интервью в день со стажерами – выполнимая задача для HR любого уровня.</p> <p>Первое что нужно понимать – стажер тоже человек. Он скорее всего, мало что знает о профессии. Но от этого он не перестает быть личностью, у которой уже есть мировоззрение, сильные и слабые стороны. Моя задача – увидеть человека через 3 года. Сможет ли этот парень или девушка через год, три, пять превратиться в толкового аналитика, разработчика? Стажеры мало что знают о профессии и о себе. На вопрос «кем вы видите себя через 3 года в нашей компании» они либо соврут, либо честно нафантазируют.</p> <p>Потому – спрашивать о навыках не имеет смысла. Имеет смысл давать задачи на общие компетенции. Потому, я действовал по следующему плану:</p> <ol> <li>Этап 1. Без моего участия.</li> <li>Для стажера-аналитика – приглашать на собеседование и отсеивать всех, кто не мог связать трех слов в предложение и тех, у кого нет высшего образования. Причина высшего образования проста: если даже человек дорастет до аналитика, его нельзя будет выводить на проекты без высшего образования в лидирующих ролях. Желательно, чтобы высшее образование хоть как-то затрагивало экономику или информатику.</li> <li>Для стажера-разработчика – приглашать на собеседование всех, кто в институте программировал. Отсеивать всех, кто на интервью сознавался в том, что пока не программировал но хочет</li> <li>Для всех стажеров давался КОТ-тест. Тест давался на бумаге, но есть <a href="https://psytests.org/iq/kot/kotB-run.html" target="_blank">онлайн-версия</a> для удаленной проверки. Этот тест занимает ровно 15 минут времени и дает оценку общих способностей человека. Дальше проходили только те, у кого больше 20 баллов</li> <li>Этап 2. С моим участием</li> <li>Задача – найти время на отсев большого количества людей</li> <li>Собирался пул анкет – от 3 до 6. Назначалось одно время интервью.</li> <li>Тесты давались всем одинаковые</li> <li>Тест на логику. В нем задачи на общую логику. Например: как, из бочки на 5 литров налить во вторую бочку ровно 3 литра, имея ведро на 2 литра. Всего штук пять задач разной сложности</li> <li>Тест на алгоритмы. В нем задачи – написать алгоритм на любом языке программирования. Обычно 3 задачи разного уровня сложности</li> <li>Пока стажеры решали задачи, я общался с тем, кто уже закончил. На собеседование 5 человек уходило 2 часа за 1 подход</li> <li>Критерии оценки тестов:</li> <li>Аналитик</li> <li>Обязательно должен решить логические задачи</li> <li>Задачи на алгоритмы решить правильно было не обязательно, но мне обязательно увидеть, что человек хоть минимально обладает способностью к алгоритмизации</li> <li>При устном общении я также смотрел на внимательность в решении задач, подачу информации, гибкость мышления, спрашивал про умение работать с нотациями BPMN, IDEF0, UML.</li> <li>Разработчик</li> <li>Обязательно решить оба теста</li> <li>Обязательно в ходе общения – иметь опыт разработки. Я считаю так: если ты программист и тебе 20-22 года, у тебя обязательно уже пробовал делать какие-то хом-проджекты, на пятерки сдавать лабы по программированию и вот это вот все. Иначе ты на самом деле не хочешь программировать.</li> <li>Этап 3. Домашнее задание</li> <li>Для программистов решение принималось по факту собеседования. Все, кто понравился и решил тесты – можно было звать на стажировку</li> <li>Для аналитиков – домашнее задание заключалось в том, чтобы прислать презентацию. Давалась произвольная тема на предмет, близкий к нашей деятельности. Например, задача звучала так: подготовить презентацию в 3 слайда на тему «Основные функции систем класса CPM». Смысл был в том, что человек сможет нагуглить нужные термины и структурировать информацию в презентацию. Это покажет навыки подготовки презентации, умение работать с неопределенностью и желание продолжать. Положительное решение принималось в случае, если человек присылал презентацию и в ней я видел способность к изложению релевантной информации. Также сразу было видно, чему его учили в институте.</li> <li>Этап 4. Начало работы</li> <li>В течение 2 недель таким образом я выводил в команду от 1 до 4 новых стажеров</li> <li>Как правило, выводили по 2 стажера на аналитику и разработку, чтобы была возможность сравнивать успехи</li> <li>К каждому стажеру прикреплялся аналитик или разработчик для наставничества</li> <li>Максимум через месяц, мы старались давать безрисковые и не срочные задачи. Как правило, стажеру-аналитику и стажеру-разработчику давалась задача доделать что-то во внутренней системе.</li> <li>Через 3-4 месяца молодых отправляли на проекты в роли юных подаванов</li> <li>Основная установка – обеспечить за первые два года участие в не менее двух проектов от начала до завершения</li> <li>Результаты</li> <li>Сегодня эти ребята работают в роли ведущих разработчиков и аналитиков</li> <li>Всем меньше 26 лет</li> <li>У всех ребят резюме позволяет устроиться на работу в течение 3 рабочих дней</li> <li>Но их никто не отпускает, потому что они приносят пользу на любом проекте, даже самом кризисном</li> <li>Процент отсева – за первый год после приема мы прощались примерно с 2 из 6 человек</li> </ol> <h2><strong>Разработчики</strong></h2> <p>Должен сказать, что разработчиков уровня мидл и выше искать проще, чем аналитиков, техлидов и тимлидов.</p> <p><strong>Что важно для меня:</strong></p> <ol> <li>Подтвержденные скилы. Мне важно понимать ,в чем прямо сейчас разраб хорош настолько, чтобы уложиться в свою собственную оценку</li> <li>Проактивность. Важно, чтобы разраб смог вовремя указать техлиду или аналитику на неточности и совместно поправить ошибки в постановке.</li> <li>Все вопросы про стек технологий – вариативно, в зависимости от проекта. Где-то нужно было в автотесты, где-то хорошо уметь в веб-сервисы, где-то нужно было уметь быстро рисовать прототипы на основании мокапов.</li> <li>При всем при этом - не тратить на тестирование и интервью большое количество времени HR’a, меня, техлида.</li> </ol> <p>В итоге, процесс строился так:</p> <ol> <li>Этап 1. Без моего участия.</li> <li>Давалась установка на ключевые слова для HR. Это были в зависимости от проекта, такие слова как УХ, веб-сервисы, работа с БСП</li> <li>По результату подбора резюме, задача HR состояла в том, чтобы кандидат до всяких предварительных встреч прошел онлайн-тест. Для этого я договорился (ну как договорился, купил) с работавшим на тот момент в бета-режиме сервисом по <a href="https://cron-plus.ru/" target="_blank">тестированию разработчиков</a>. О нем ниже напишу поподробнее.</li> <li>В результате тестирования мы рассматривали разрабов, у которых был средний балл выше 5,5. Если балл был выше 7 – реагировали очень быстро и понимали, что это, вероятнее всего, очень интересный кандидат</li> <li>Этап 2. Интервью</li> <li>С теми, кто добрался до интервью – я общался на предмет стандартных вещей с позиции руководителя – адекватность, мотивация и то, о чем писал выше</li> <li>Долго общаться с разработчиком – лишено смысла. За первые 5 минут понятно, сработаетесь ли вы при прочих равных в виде компетенций</li> <li>Техлид общался с разрабом. Идеально – посмотреть на разработки, которые человек уже делал, обсудить.</li> <li>В некоторых компаниях, где я работал, мы давали обязательные тесты. Но тест на 2 часа не так показателен, нежели база его наработок.</li> <li>Наличие стандартов разработки внутри компании - хорошо, включается в собеседование с техлидом</li> <li>Результаты</li> <li>Поиск разработчиков - наиболее четкий процесс, за счет наличия онлайн-тестов и возможности посмотреть на код. Код либо хороший, либо нет.</li> <li>Поиск разработчиков обычно занимал не более 2 недель при адекватном уровне дохода со стороны компании</li> <li>Не было ни одного случая, когда мы ошиблись в уровне разработчика. И в его soft-skills</li> </ol> <p><strong>Про онлайн-тестирование. </strong></p> <p>Еще когда мы работали с ребятами из i-cron.ru на предмет привлечения удаленных разрабов, я узнал про сервис, который они делают. Что дает сервис – он дает средний балл на основании теоретического тестирования разработчиков. Первое что я сделал – прогнал всех своих разрабов через этот тест. Результат теста соответствовал их реальному уровню. Мидлы имели 5.5 и выше, ведущие разрабы и техлиды – от 6.5 до 7.8. Однажды я уговорил крутых ребят, которые от 1С обеспечивают на Ростехе релизы, пройти тест. В итоге мне через 10 минут позвонил Ранис, который эти тесты проверяет на своей стороне и сказал что у нас какой-то очень крутой спец прошел тест. Да, все тесты на той стороне проверяются вручную.</p> <p>После того, как я убедился в том, что тест дает чаще всего точную оценку, я принял решение, что готов на такую погрешность при первичном тестировании новых людей.</p> <p>Каждому кандидату выдавался тест. Для того, чтобы застраховаться от рисков, я вводил их данные в тест в обезличенном виде. По каждому участнику получался вот такой (См. скрин) результат. Я мог при необходимости посмотреть ответы на каждый вопрос. Получилась сводная таблица с результатами.</p> <p>Для меня этот тест давал экономию времени, возможность сопоставить результаты тестирования и определить сильные стороны.</p> <p>Иногда тест давал погрешность за счет того, что ответы, которые были скопированы разработчиком с того же сайта ИТС определялись как копипаст. Но по итогу, погрешность оказалась незначительной, а в скопированных ответах я мог порыться и выяснить на собеседовании эти пробелы.</p> <p>Для меня этот тест – первый барьер, чтобы допустить человека до интервью с техлидом и потратить наше с ним время.</p> <p>А для тех, у кого техлида нет (либо это HR, либо инсорс без сильного специалиста которому доверяют) – тест в принципе задает систему координат. Достаточно объективную. Так что могу сказать экспертно - штука стоящая, все рекомендую как первичный отбор разработчиков всех уровней начиная с Джуна.</p> <p></p> <figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_6e914cb05d55418d8df90d5c41ae3e90~mv2.jpg/v1/fill/w_468,h_949,al_c,q_90/137802_6e914cb05d55418d8df90d5c41ae3e90~mv2.webp" width="468" /> </figure> <h2><strong>Аналитики</strong></h2> <p>Для моих проектов, которые были в сфере корпоративных финансов, аналитик – самая сложная позиция. Нет единых стандартов, стека технологий и вообще, единого понимания задач аналитика на рыке.</p> <p>Потому задача HR сводилась к тому, чтобы по ключевым словам типа УХ, Казначейство, Бюджетирование, БИТ.Финанс – выделить вакансии и отправить мне.</p> <p>Что я смотрел:</p> <ol> <li>Первым делом смотрел резюме. Очень часто оказывались знакомые, которые могли дать референс</li> <li>Проактивность человека. Тех кто хотел работать работу я определяю как правило за 5 минут встречи</li> <li>Навыки ИТ-аналитика. А именно:</li> <li>Пример ТЗ. Это могло быть что угодно – ФТ, ТЗ, КТ, ЧТЗ, аналитическая записка, отчет об обследовании. Главное, что нужно определить – способность формализовать, выявлять скрытые требования, отделать бизнес-требования от функциональных и от технических, способность донести каждый из этих видов требований</li> <li>Грамотность. Это отдельный важный пункт. Нельзя быть неграмотным</li> <li>Умение в базовую архитектуру 1С. Спустя годы работы в 1С, я утверждаю, что аналитик, который не понимает разницы между РС и РН, а также не может написать запрос в консоли и не знает что такое консоль – не имеет шансов на успех на моих проектах</li> <li>Умение в схемы. Нарисовать за полчаса схему в BPMN – базовый навык</li> </ol> <p><strong>Кого я точно не брал:</strong></p> <ol> <li>Тех кто пришел из предметки. Профессия фин.контролера и профессия системного аналитика – разные. Вероятность успеха – 50%, время на обучение – не меньше года. Так как на проект нужно выводить готового аналитика, вывести на проект бывшего кей-юзера стремится к нулю</li> <li>Тех кто не соответствует уровню аналитика минимум Стандарт (<a href="https://t.me/RussianAutomatization/1609" target="_blank"><u>см. это видео</u></a>). Вообще, это видео крайне полезное для понимания функций аналитика. Рекомендую всем аналитикам для себя и HR&#x27;ам для подбора.Я теперь это видео даю посмотреть стажерам перед очным интервью.</li> </ol> <p><strong>Что могу сказать по результату</strong></p> <ol> <li>Первые 5 минут - самые показательные. За 5 минут впечатление о возможности совместной работы сформировано. Оставшееся врем - продажа вакансии, определение текущего уровня компетенций и финансовых ожиданий.</li> <li>Значительную часть людей я привлекал не через HR, а через свои контакты или через нетворкинг в моем телеграм-канале</li> <li>Аналитики всегда хотят оклад не ниже чем мидл-разработчик. При этом, почти никто из них не умеет в мокапы, качественное отражение процессной модели, не говоря уже о функциональной</li> <li>Самый работающий способ – растить своих аналитиков из стажеров. За 3 года вполне можно вырастить.</li> <li>Если нет времени ждать – нужно брать среднего аналитика за умеренные деньги, еще не словившего звездную болезнь и тренировать его на полном жизненном цикле проекта</li> <li>Если нужен тимлид – нужно брать только из известных мест с референсом людей, чей процесс создания ценности тебе хорошо знаком, предлагать много денег. Найти на рынке с гарантией срока и качества – практически невозможно.</li> </ol> <h2><strong>Выводы</strong></h2> <ol> <li>Решение задачи подбора специалистов путем формализации заявки на специалиста и не-участия РП и/или тимлида, техлида - пустые надежды. Либо не найдется, либо найдется не тот человек.</li> <li>В отрасли 1С много компаний, которые ищут специалистов по 1С разного плана. Рынок не стандартизирован.</li> <li>Искать людей сложно, предложить специалистам что-то уникальное кроме уровня дохода – сложно. Нужно много думать о том, что ваша компания предлагает специалистам в части роста, комфорта, удобства, окружения.</li> <li>Нужно, чтобы на этапе интервью был человек, который сможет продать кандидату особенности работы. Что может быть уникально: личности, наличие эффективного процесса, для некоторых – география, для многих – перспектива развития именно в этой предметной области автоматизации.</li> <li>Многие из тех разрабов и аналитиков уходят спустя полгода-год не из-за денег, а из-за регулярной хаотичности процессов и недостатка коллег с равным или более высоким уровнем компетенций</li> <li>HR на рынке обычно ограничиваются поиском резюме на hh.ru. Редкие HR’ы публикуют вакансии в <a href="https://t.me/joboneC" target="_blank">телеграме</a> или ищут народ в линкдине. В линкдине в основном ищут корпорации и вот это вот все.</li> <li>Рекрутинговые агенства не всегда полезны, т.к. у них те же источники. Преимущества – компетенции по нетворкингу самих HR’ов, которые выуживают контакты у тех, с кем они уже общались ранее</li> </ol> <h2><strong>Полезные ссылки</strong></h2> <ul> <li><a href="https://t.me/joboneC" target="_blank"><u>Телеграм канал </u></a>с вакансиями. Рекомендую HR&#x27;ам для размещения</li> <li><a href="https://cron-plus.ru/" target="_blank"><u>Онлайн-сервис</u></a> КРОН для тестирования разработчиков</li> <li><a href="https://t.me/RussianAutomatization/1609" target="_blank"><u>Видео про уровни</u></a> и задачи аналитика</li> <li><a href="https://psytests.org/iq/kot/kotB-run.html" target="_blank"><u>КОТ-тест</u></a>. Рекомендую всем HR&#x27;ам и РП. Рекомендую прогнать всех, но хотя бы стажеров.</li> </ul> wangoff:8XrKiEDhfh12021-08-22T18:49:39.968Z2021-08-22T18:49:39.968Z

<img src="https://static.wixstatic.com/media/137802_4685e1af6242468dbaa0180f21c586c3~mv2.jpg/v1/fill/w_814,h_521,al_c,q_90/137802_4685e1af6242468dbaa0180f21c586c3~mv2.webp">Если вы набрали больше 3 "Да" - поздравляю. У вас - УкСУС.

<figure class="m_original"> <img src="https://static.wixstatic.com/media/137802_4685e1af6242468dbaa0180f21c586c3~mv2.jpg/v1/fill/w_814,h_521,al_c,q_90/137802_4685e1af6242468dbaa0180f21c586c3~mv2.webp" width="814" /> </figure> <ol> <li>Вы не можете за 5 минут найти детальное описание любого требования, которое было реализовано в системе вашей командой?</li> <li>Вы не можете за 5 минут разобраться во взаимосвязи требований между собой?</li> <li>Ваш проект превышает объем 4000 часов?</li> <li>Файлы с ФТ/ТЗ не проходят по лимитам файервола заказчика?</li> <li>Требования к системе описаны в ворде?</li> </ol> <p>Если вы набрали больше 3 &quot;Да&quot; - поздравляю. У вас - УкСУС.</p> <p>Привет, дорогой друг. Сегодня мы поговорим о болезнях ИТ проектов. А именно - о таких болезнях, как <strong>УкСУС </strong>(lat. Устаревшая система управления содержанием). Разберемся, что к чему, как лечить и кто в зоне риска.</p> <p><strong>УкСУС. Устаревшая система управления содержанием</strong></p> <p>Болезнь описана в сообществе сравнительно недавно. В общем смысле, болезнью и не является. Скорее, отклонение от нормы, которое ранее отклонением не считалось. Но приводит к системному кризису организма проекта.</p> <p>Подобное отношение к норме в истории уже происходило:</p> <ul> <li>В 19 веке чернокожих людей не считали равными белокожим. Сегодня такое отношение не считается нормой и подвергается общественному остракизму</li> <li>До 2019 года считалось, что невозможно управлять страной через телевизор. Сегодня же это норма в менеджменте для всех стран земного шара</li> </ul> <p>Примерно так же до недавнего времени считалось нормой управлять содержанием сложных систем с помощью электронных документов.</p> <p>Однако сегодня психологи от АйТи признают, что подобный паттерн поведения на проектах объеме более 4000 часов приводит к системной депрессии, кризису и нервному срыву проекта.</p> <p>Ранее подобные проблемы считались нормой и принимались в обществе как данность. Но в связи с прогрессом ИТ-медицины, информация о возможности излечения подобного недуга и связанных с ним проблем, распространилась по миру и докатилась до России и до самых ее отдаленных углоков. Потому, даже неопытные пациенты спустя месяц наблюдения симптомов с помощью вакцины гугления приходят к ответам на самые сокровенные вопросы.</p> <p><strong>Возбудители болезни</strong></p> <p>Имеет не инфекционную природу. Но психологическую.</p> <p>Если кратко: реализация информационной системы, как правило, лежит на пересечении процессной и функциональной модели. Требования к системе как правило находятся на персечении двух этих моделей. С одной стороны, для поддежания архитектурной целостности системы, требуется сохранить целостность функциональной модели. Это значит, что требования должны быть правильно отражены в функциональной модели системы.</p> <p>С другой стороны, смысл реализации любой системы - нанести пользу бизнесу, а ингода и бизнес-пользователям. А значит, проверка работоспособности системы производится на основании бизнес-кейсов, которые коррелируют с процессной моделью системы.</p> <p>Отсюда - проекция этих двух моделей друг на друга порождает высокую сложность поддержки и обновления содержания системы. Добавим сюда ролевую модель, управление разработкой, сервис-деск и управление сроками реализации.</p> <p>Как следствие, подобные противоречивые импульсы порождают кризис личности и приводят к непоправимым изменениям в психике менеджмента проекта.</p> <p><strong>Народные методы лечения </strong></p> <p>Как правило, столкнувшиеся с данной проблемой пациенты практикуют эскапизм - уход от проблемы в угоду четко указанным в договоре пунктам. Что иногда приводит к финансому результату. Но не ведет к повышению уровня счастья в мировом океане, а также вызывает хроническую аллергию на продукт и команду со стороны бизнес-пользователей. Сюда же относится метод лечения путем игнорирования проблем на проекте. Как правило, завершается изгнанием менеджера или команды целиком.</p> <p>Второй способ борьбы с проблемой - завалить проект людьми. Эта концепция проистекает из гипотезы, что 100 человек могут решить организационную проблему, которую не решили 20. Как правило, такое лечение прерывается в связи с окончанием финансирования.</p> <p><strong>Особенности лечения</strong></p> <p>Для снижения рисков провала проекта, необходимо наладить управление содержанием внедряемой системы. Команды, которые принимают данный риск, как правило, сталкиваются с описанными выше симптомами: срыв сроков, бедное содержание, негатив заказчика, невозможность передачи на поддержку, большое количество ошибок, бесконечный беклог от пользователей, бессонные ночи.</p> <p>Нужно отметить, что лечение не тривиально и произвольно выбранный врач из поликлиники, не имеющий профильной подготовки, может даже навредить организму команды проекта.</p> <p>Также важна дисциплина в лечении и соблюдение рекомендаций всеми участниками процедуры лечения.</p> <p>Лечение имеет ряд побочных эффектов, потому не рекомендуется пациентам с нехарактерными симптомами - проекты низкой сложности, отсуствтие разработки, низкая зрелось команды.</p> <p><strong>Лечение</strong></p> <p>Для снятие первых симптомов пациенты как правило самостоятельно принимают пилюли тасктрекинга. Производителей довольно много - Jira, Trello, Redmine, самописные продукты на платформе 1С и множество иных.</p> <p>При обращении к врачам, методы сильно разнятся. Известны следующие стратегии лечения:</p> <p><strong><em>1. Стратегия умных западных систем.</em></strong></p> <p>Пример - стек технологий Atlassian.</p> <p>Внедряется collaboration-система Confluense, которая возволяет хранить содержание всего проекта (и портфеля также), проводить обсуждение и согласование.</p> <p>Более формальное определение: Collaboration — система, отвечающая за электронное взаимодействие людей, но не формализованное, как<strong>workflow</strong>, и не просто &quot;архив&quot;, как EDMS.</p> <p>Внедряется Jira, которая решает задачи</p> <ol> <li>Таск-стрекера</li> <li>Релиз-менеджмент</li> <li>Планирование спринтов проекта</li> <li>Описание тест-кейсов</li> <li>Учет времени (актуально для платных команд внедрения)</li> <li>Прочие задачи, определяемые ответственным за внедрение и использование данной системы</li> </ol> <p>Более дешевый аналог &quot;all-in-one&quot; - отечественный Битрикс. Имеет более широкий функционал в части CRM, более бедный в части функций collaboration. И вообще, ориентирован больше на продажи и управление малым бизнесом.</p> <p><strong>2. Стратегия Все и 1Сразу</strong></p> <p>Стратегия, широко применяемая при автоматизации бек-офиса в странах СНГ. Заключается во внедрении Системы проектирования прикладных решений - решения, производимого и поддерживаемого фирмой 1С.</p> <p>Класс системы можно определить именно как &quot;Система управления содержанием&quot;. Для использования на проектах не-1С невозможна по причина возникновения острой аллергии на пыльцу с цветов желтого цвета.</p> <p>Решает следующие задачи: управление процессной и функциональной моделью, управление поставками, ролевой модели. Отличительной особенностью является механизм контрольных точек, который позволяет формализовать процесс поставки ценности.</p> <p>Характеризуется кандовостью итерфейса, отсустствие юзабилити как класса.</p> <p>Побочный эффект - бюрократизация процесса внедрения.</p> <p>На рынке имеются узкие специалисты по эксплуатации системы. Их место обитания находится <a href="https://t.me/SPPR_1C" target="_blank"><u>здесь </u></a></p> <p>Не является системой учета задач. Интеграция с любыми известными таск-трекерами отдается на откуп пациентам.</p> <p><strong>Про пилюли</strong></p> <p>Сегодня на рынке много пилюль, на коробке которых написано примерно одно и тоже. Управление командами, проектами и вообще. Помните, что курс лечение – дело ответственное и доверять его нельзя кому попало. Но и откладывать нельзя.</p> <p><strong>Про лекаря</strong></p> <p>Лекарь должен сочетать в себе ряд характеристик и навыков:</p> <ol> <li>Иметь опыт работы в качестве аналитика, функционального архитектора</li> <li>Иметь продуктовое видение и видение результата своей деятельности в частности</li> <li>Понимать стоимость проведения изменений в компаниии</li> <li>Иметь полномочия на директивные методы проведения изменений</li> </ol> <p>Лекарь может иметь свои наработки и ноу-хау по стратегии лечения, стеку технологий,но они в той или иной мере будут коррелировать с описанными выше стратегиями. Как минимум, идейно.</p> <p><strong>Не болейте!</strong></p> <p>В следующий раз поговорим про такую болезнь, как АПОЖ.</p>