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