пятница, 30 октября 2015 г.

Идеальный состав отдела САПР

Идеальных людей не бывает. Идеального отдела САПР - тоже.

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

Во-первых, САПР должен относиться к IT.  
САПРу очень часто необходимо настраивать сервера, подключать ключи, разворачивать лицензии ит.д. Если у специалистов нет доступа - будут либо замкнутые циклы, либо попытки сломать защиту, которую наделали сисадмины. Если не хотим проблем - работаем вместе.
Более того, не сисадмины диктуют требования, а САПР. САПР определяет какое железо нужно пользователю, САПР определяет как будет развернут сервер лицензий.
В большинстве случаев САПР - это та служба, которая оказывает прямое влияние на эффективность основного бизнес-процесса: выпуск проектов. Если службы IT блокируют работы САПР, они нарушают основной бизнес-процесс. Это в обязательном порядке должны понимать все участники процесса (особенно руководители!).
При этом у специалистов САПР совершенно необязательно должны быть в наличии знания по системному администрированию. В этом контексте САПР - постановщик задачи.

Я не единственный человек, который недолюбливает службу IT. Мне как-то писали, и даже звонили, с просьбой посоветовать как действовать. Увы, я тут ничем помочь не могу, должна быть воля и понимание начальства: кто за что в ответе. 
Единственное, чего я никак не могу понять, почему никого не волнует время этапов жизненного цикла? 
Если несогласованность служб приводит к увеличению времени выпуска проекта - почему на это никто не влияет?
Автоматизация ради автоматизации, безопасность ради безопасности...это происходит повсеместно! И от этого надо избавляться.

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

Таким образом, на один только AutoCAD нужен следующий состав специалистов:

1. Руководитель

Руководитель - это в первую очередь лидер. Хотя в контексте проектных организаций, он должен понимать что такое САПР.
Руководители бывают разных уровней - высшее звено руководства и линейное звено.
Высшее звено - это начальники отделов. Начальники отделов - это, своего рода "связь с общественностью".  Т.е. начальник ведет внешние переговоры - с начальниками других отделов, с топ-менеджментом. Обеспечивает бесперебойную работу отдела.
В чем проблема САПР в этом вопросе. Мы подчинены пользователям, пользователи же нас могут и любить, и ненавидеть. Но ни в коем случае задачу пользователь ставить вам не может, а они это очень любят - "ну что вы там в своем САПРе сидите, не можете придумать как мне галочку поставить?!". И спасет только начальник отдела. Если вы рядовой специалист службы САПР, задачу вам ставит ваш руководитель или начальник отдела. В противном случае, вы сделаете большой объем работы и никто за это вас не похвалит.
Мой личный взгляд на начальника отдела: это человек, который защищает меня от нападков со стороны. И обеспечивает мне наиболее комфортные условия работы (я тоже ехидно улыбаюсь, у меня таких начальников пока что не было). 
Вообще вопрос высших звеньев очень скользкий и зависит от многих параметров - концепции компании, топ-менеджмента ит.д., поэтому остановимся на том, что есть.

Руководитель линейного звена или руководитель группы. Вот этот человек в обязательном порядке должен иметь опыт работы с САПР. По сути , это идейный вдохновитель. Он в рамках общей концепции и общей задачи должен формировать задания рядовым сотрудникам.
При этом обладать навыками самостоятельно решать задачи, не требующие программирования: создание развертывания, шаблонов, инструментальных палитр и динамических блоков.
Такому руководителю должна в первую очередь принадлежать идея. Зачем нам развертывание?! "У меня на это 5 причин"...а реализовать может и студент, под чутким руководством идейного вдохновителя.
За ошибки отвечает именно линейный руководитель, потому что остальные выполняли выданные им задания.
Бывает так, что рядовые сотрудники уже выросли из обычных исполнителей и могут инициировать задачи самостоятельно. В этом случае линейному руководителю не стоит расценивать их как соперников на должность, а рассмотреть предложение и оказать посильную помощь в реализации, возможно, возложив некоторые руководящие функции на этого сотрудника.
Мой личный опыт говорит о том, что ни в коем случае линейным руководителем не должен быть тот, кто дольше всех работает. По той причине, что это люди наевшиеся всего - и с маслом, и без...и в большинстве случаев придерживаются мнения: лишь бы работало. Новаций от них ждать не приходится. Хотя...бывают и противоположные случаи. Но, назначая руководителя, не отталкивайтесь от времени работы в компании, нужны личные качества: человек должен уметь отвечать за свои действия и находить подход к своим подчиненным, стремиться к развитию. Нежелание меняться в САПР - это большая проблема, поэтому руководителю стоит быть в курсе всех новых трендов, но при этом понимать что для вас нужно, а что может на полочке полежать.


2. Специалист технической поддержки

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

Если хелпдеск не внедрен, то САПРу лучше не изобретать велосипед, а просто обозначить задачу перед ИТ. Нужно учесть, что САПР - это область, где принципиально важны "картинки". Хэлпдеск, в который нельзя прикрепить скриншот, бесполезен.

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

Но вернемся к специалисту технической поддержки. Человек должен полностью знать функционал САПР, чтобы своевременно решать поставленные задачи.  Это ваше окно к пользователям и предпочтительно, чтобы этот человек не занимался другими проблемами.
Знание корпоративных стандартов и стандартов ГОСТ Р (ЕСКД, СПДС) также обязательно. Нельзя позволять пользователю чертить на альбомном A4, так как такой чертеж потом отклонит нормоконтроль...жизненный цикл за счет мелкой ошибки будет удлинен - кому это надо?!

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

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

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

В идеале на каждое ПО - свой техсаппорт. В реальности получается, что техсаппорт знает все и отвечает на все вопросы. Я бы разделила техсаппорт хотя бы по направлениям.

3. Программист

Забудьте проблему "ТыЖпрограммист". Программист - это не сисадмин, не специалист по железу, не электрик, не кад-менеджер, не техподдержка. Программист что должен делать?! Программировать. И все...Чем больше программист отвлекается от программирования, тем сильнее вы будете ненавидеть написанный им код.

Если бы я принимала решения, я бы взяла трех разноплановых программистов:
1. LISP (или VBA, .NET, но именно на тот САПР, который используется). Этот человек делает надстройки на существующее ПО.

2. Тут во мне программист умер)) Человек, который может создавать свое ПО, писать базы и пр. Понятия не имею как это называется правильно: C#-программист?!

3. Специалист по веб-дизайну/мобильным приложениям/UI (интерфейс). Желательно, чтобы это были разные люди, и совершенно необязательно, чтобы у вас был весь перечисленный набор. Но уделять внимание юзабилити продуктов надо ("делайте интерфейс так, как будто ваш пользователь пьян"-помните такой ролик?).

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

4. Рядовые сотрудники

Это исполнители. Что тут можно сказать. Вчерашние студенты? - сюда. Опытные специалисты без амбиций? - сюда. Девушка вышла из декрета и еще не "въехала" - тоже сюда.
Количество рядовых сотрудников зависит от поставленных задач. Бывают ситуации, когда они совсем не нужны (после качественного внедрения).


От чего количество сотрудников в САПР может увеличиться?

Нас в отделе 8 человек. 3 программиста, 3 на техсаппорте (это мы так называем, на самом деле все намешано и перепутано), 1 главспец и 1 начальник. И есть люди, которые считают, что нас слишком много (человек, я знаю, что ты почитываешь мой блог - привет тебе!).

Почему возникают ситуации, когда сотрудников САПР почти столько же, сколько и пользователей?! На самом деле возможны только 2 сценария:
1. САПР очень эффективен
2. САПР абсолютно неэффективен.

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

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

Кто должен устанавливать ПО САПР?

Вот сейчас можете меня закидать камнями. Установкой ПО служба САПР НЕ ЗАНИМАЕТСЯ!
Во-первых, мы достаточно компетенты, чтобы этого не делать. Во-вторых, мы не обязаны знать как у вас настроены доменные политики, куда ходить можно, а куда-нельзя.
Мы готовим вам образы (развертывания AutoCAD), все настройки прописаны уже там, а нажимать кнопочку "Далее" могут любые эникейщики, донастройкой займется наш техсаппорт. Это проблема встает остро в случае, когда САПР и IT - разные подразделения разного подчинения. Стрелок будет много, в конечном итоге ваш высококвалифицированный специалист, а иногда программист (серьезно?! он же забудет синтаксис языка!),  будет, матерясь через слово, устанавливать ПО и контактировать с пользователем вместо техсаппорта.

Если пользователь видит помощь в ком-то конкретном, он начнет постоянно обращаться к этому человеку. Оно вам надо?!

В моей практике бывают случаи, когда пользователь заходит в кабинет своими ножками (и не лень ему), спрашивает конкретного сотрудника, на ответ, что тот в отпуске/на больничном, начинает разворачиваться к выходу с недовольным лицом. Самое время спросить - я могу вам помочь?! Что делает пользователь? Ни за что не догадаетесь. Он строит еще более кислую мину, говорит "НЕТ, вы не способны мне помочь!" и уходит. Вчера только читала статью "Как на самом деле думают о пассажирах стюардессы?". Так вот, найдите - почитайте. Скорее всего сотрудник САПР выбирает выражения по-горячее, даже если это кавайная девушка и  мило улыбается вам в след.

Я бы посоветовала топ-менеджерам внимательно взглянуть на свои информационные структуры. В больших госкорпорациях уже давно присутствует "выслужливость" перед начальством. Внедрение спускаемых сверху систем проходит - лишь бы было что показать, при этом эффективность процессов не увеличивается. Скорее всего и отчетность будет идеальная, и циферьки подобьют - мы подняли производительность труда в 5 раз! Орден!
Все не так просто. САПР занимает важную роль в бизнес-процессах, к САПРу прикреплены задачи документооборота. Неэффективная работа САПР - это проблема,которой нужно уделять внимание: грамотно мотивировать сотрудников, осуществлять поддержку проектов на высоком уровне, быть открытыми к новым идеям.