Песочница →
Организация работ с подрядчиками в ИТ
Интересуют мнения по теме с обеих сторон баррикады. Тех кто предоставляет услуги ИТ и тех, кто по роду деятельности взаимодействует с подрядными организациями. Сразу просьба учитывать что все написано со стороны интересов именно потребителей ИТ услуг.
Все нижеизложенное было написано с точки зрения компаний деятельность которых не связана с информационными технологиями и ИТ рассматривается как инструмент увеличение эффективности основного бизнеса. На примере информационной системы, написанной с нуля или сильно кастомизированной под процессы компании.
Подразумевается, что компания доросла до осознания факта – всем по части компьютеров и информационных технологий не может заниматься один бородатый мужик в футболке с надписью «Админ шоколадки не пьет». Занимаясь всем, от заправки картриджей для принтера до администрирования серверов и написания кода на нескольких языках программирования.
Любое компьютерное приложение – это продукт. Как, например бумага. Она нужна в каждом офисе, но никто же не создает цехи по производству бумаги при каждом офисе. Ее просто покупают. Программный продукт так же должен закупаться у тех, кто его создает на профессиональной основе.
Вариант нанять одного или двух человек, которые все напишут – вообще не должен рассматриваться. Т.к. при таком раскладе качественно вести документирование вряд ли кто будет. И в случае ухода этих людей разобраться в том, как работает то, что они создали, будет очень сложно. А если говорить о системе, на которой построены процессы работы компании – то эта проблема становится бизнес и финансово критичной.
Нанять организацию предоставляющую услуги ИТ консалтинга передав ей полный ИТ суппорт бизнеса тоже не правильно.
Допустим, предприятию повезет, и в качестве подрядчика выберут профессиональную команду. Тогда они действительно все сделают – соберут требования, проведут анализ, напишут и внедрят продукт. Поставив весть бизнес в зависимость от них. Ведь кроме них никто не будет знать, как все это работает. Следовательно, нужна поддержка на постоянной основе. По цене, которую предложат они.
Просто ценой за поддержку никто не ограничится. Цены за развитие продукта значительно выше. А сделать так, что бы ваш бизнес всегда требовал развития и доработки их продукта для опытных людей не составит труда. А ведь наняли то профессионалов, не забывайте.
И еще, при таком сценарии они получают доступ к значительной части внутренней конфиденциальной информации компании. Да конечно будет подписано соглашение о неразглашении. Но думаю, не все согласятся доверить свою коммерческую тайну посторонней организации. Даже при наличии договора о неразглашении.
Они отдельная организация. И как в любой организации у них одна цель – заработать денег. Просто бизнес и ничего более.
По моему мнению – правильно разделить процесс разработки. Где анализ и постановка задач формируется внутри организации, а непосредственно разработка – передается подрядчику.
Для организации нормальной работы, как с подрядчиком, так и внутри организации, нужно создать команду. В самом простом случае я вижу в этой команде 4 роли. Плюс подрядчик как одна роль.
Менеджер (владелец системы)
Что делает
Определяет стратегию развития, в каком направлении развивается система, что будет нужно предприятию от этой системы через год, возможно два. Утверждает бюджеты. Отвечает за работу с подрядчиком в целом. Утверждает задачи подрядчику. Устанавливает приоритет по задачам.
Что не делает
Не является руководителем компании (руководитель должен максимально делегировать такие задачи на подчиненных, занимаясь целевым вопросами целевого бизнеса). Возможно заместитель или руководитель одной из функций. Но не ИТ. Не занимается вопросами, как развивать систему. Т.е. ставит задачу – нужно увеличить надежность хранения данных. Не затрагивая вопроса как собственно увеличить.
Характеристики
Человек, полностью понимающий основной бизнес компании. Имеющий большой опыт работы в разных функциях компании. Имеющий определенный авторитет и политический вес в компании. Административно не относится к структуре ИТ и не являющийся специалистом по ИТ технологиям.
Аналитик
Что делает
Описывает текущие процессы в компании в виде внутренних документов.
Разрабатывает и предлагает руководству оптимизацию существующих процессов и внедрение новых. Например, сейчас на составление одного договора с клиентом у продавца уходит 2 часа времени. В процессе анализа установлено что, если реализовать автоматическое составление и печать, то на подготовку договора будет уходить 2 минуты.
Превращает пространственные пожелания внутренних заказчиков в конкретный документ – бизнес требования. Отвечает за соответствие бизнес требований изначальным пожеланиям заказчиков.
Получает от подрядчика предложения по внедрению новых решений, продуктов и доработок. Анализирует насколько они необходимы компании. Если необходимы, предлагает руководству компании их внедрение.
Что не делает
Не принимает управленческих решений, только предлагает их. Не устанавливает приоритеты по задачам для подрядчика. В общих чертах разбирается в ИТ и поэтому не передает абсолютно нереализуемые идеи архитектору. В переговорах с подрядчиком не имеет права на собственное мнения – озвучивает только то, что согласовано с руководством.
Характеристики
Очень хорошо разбирается в процессах предприятия. Может предложить, как оптимизировать работу отдела или отдельного сотрудника, даже если сам сотрудник этого сказать не может. Поверхностно разбирается в ИТ технологиях. Важно что бы аналитик был своим, а не привлеченным со стороны подрядчика. Иначе это чревато развитием ради зарабатывание подрядчиком денег.
Архитектор
Что делает
Если менеджер определяет стратегию в каком направлении развивается система, то архитектор определяет как она развивается. Т.е. техническую сторону стратегии развития. Отвечает на вопросы типа, сколько серверов нужно привлечь для обеспечения работы системы при увеличении нагрузки, которую создадут 20 новых сотрудников, которых компания планирует привлечь в следующем году.
Пишет технические задания по предоставленным аналитиком бизнес требованиям и передает их подрядчику. Отвечает за соответствие технического задания бизнес требованиям.
Получает от подрядчика план работ по тех. заданию с оценкой трудозатрат. Анализирует предоставленный план на предмет завышения трудозатрат. В случае необходимости согласовывает с подрядчиком внесения правок. Утверждает план работ перед тем как его подпишет менеджер.
Проверяет предоставленный подрядчиком пакет на соответствие техническому заданию. Принимает участие в тестировании. Принимает решение о приемке работ и переносе изменений на основную среду.
В переговорах с подрядчиком должен иметь свою позицию в вопросах как это будет делаться. Но вопросы что делать определяет менеджер.
Что не делает
Не делает самостоятельные доработки системы. Не исправляет обнаруженные в процессе тестирования дефекты или несоответствия тех. заданию. Только уведомляет о них подрядчика. Не занимается администрированием или поддержкой приложения.
Характеристики
Должен обладать абсолютными знаниями по системе. А так же глубокими знаниями как технологий так и процессов ИТ в целом. Уметь вести переговоры, грамотно аргументировать свою точку зрения – от него зависит конечная цена работ и качество получаемого продукта.
Администратор
Что делает
Работает с пользователями. Заводить и удалять из системы, обнулять пароли. Консультировать по вопросам типа, что нужно нажать что бы открылась эта форма или почему неактивна та кнопка.
В установленные сроки реагирует на сбои и ошибки системы. Должен уметь перезапускать службы и перезагружать сервера. Выполнять другие шаблонные действия для поддержания или восстановления работоспособности системы. В случае аварий которые он не в состоянии решить, грамотно описать проблему и передает ее подрядчику в рамках договора о поддержке.
Устанавливать полученные от подрядчика пакеты на тестовую среду. Принимать участие в приемочном тестировании пакетов на тестовой среде. Устанавливать пакеты на основную среду после приемки работ.
Составляет паспорт, договор о предоставлении услуг пользователям и другие внутренние документы по системе.
Все действия которые может производить администратор должны быть описаны в «Руководстве администратора» которое составляет поставщик системы и поддерживает его актуальность после обновлений и доработок системы.
Что не делает
Не производит собственных доработок или изменений системы.
Характеристики
По сути, его работа это сплошная рутина. От него не требуется особых знаний. Должен выполнять пару десятков операций. Большинство из которых должны быть описаны в «Руководстве администратора». Но требуется внимательность стрессоустойчивость и ответственность.
Подрядчик (понятно, что со стороны подрядчика так же работает целая команда, но с точки зрения заказчика – они единое целое)
Что делает
Получает и анализирует техническое задание от архитектора. Предоставляет архитектору план работ с указанием трудозатрат своих менеджеров, аналитиков, программистов, тестировщиков. После согласования и уточнения плана, получает подписанный менеджером заказ на работы и оплату за работу аналитиков создававших этот план. Выполняет работы по согласованному плану. Предоставляет администратору пакет с изменениями и измененную версию руководства пользователя. После тестирования и подписания акта о приемке работ получает оплату.
Основываясь на своем опыте предлагает решения аналитику компании (и только аналитику).
Что не делает
Не занимается сбором требований и анализом процессов в компании. Любой анализ процессов со стороны подрядчика чреват решениями, которые не столько нужны компании, сколько должны принести доход подрядчику.
Не делает никаких предложений по системе никому кроме аналитика (по бизнес части) или архитектора (по технической части). Попытки «продать» какое либо решение бухгалтерам, маркетингу, продажам или кому то еще должны пресекаться с публичным наказанием виновных.
Не имеет доступа к основной среде. К тестовой среде – возможно, но без права внесения изменений. Вся разработка должна вестись на девелоперской среде.
Характеристики
Роль подрядчика должна сводиться к предложению решений на основе своего опыта аналитику компании и написанию кода по техническому заданию полученному от архитектора.
Пара слов о договорах
Между компанией клиентом и подрядчиком должно быть заключено два независимых договора.
Договор о поддержке. Описывает сроки предоставления решений по критическим авариям, которые не может решить собственный администратор и штрафы за нарушение этих сроков. Договор о поддержке – более дешевый. Им можно частично компенсировать убытки, понесенные из-за неисправности информационной системы (если до этого дойдет). Поэтому желательно, что бы он всегда был актуальным и своевременно перезаключался. Вместе с собственным администратором – это инструмент защиты бизнеса от ИТ-шных сбоев. В случае ухода собственного администратора временно можно полностью переложить задачи администрирования на подрядчика. В случае проблем с перезаключением договора о поддержке – есть собственный администратор который возьмет на себя полную поддержку системы пока договор таки не будет продлен на следующий период. В штатной ситуации должен быть и свой администратор и договор о поддержке.
Договор о развитии системы. Рамочный договор, который описывает порядок передачи заданий клиентом подрядчику, порядок приемки выполненных работ, оплат, решения спорных вопросов. Здесь же должны быть прописаны цены на услуги подрядчика. Например, стоимость единицы времени каждого ресурса подрядчика (аналитика, программиста и т.д.). Даже в случае его отсутствия это не влияет на текущую работу компании. Обеспечивая независимость бизнеса от подрядчика. Да, новых функций не будет, но хоть все текущие будут работать. В крайнем случае, можно будет объявить тендер на развитие системы и передать развитие другой организации. Документация по системе в компании есть, архитектор со своими знаниями тоже. Но это в самом крайнем случае, поддержкой и развитием должна заниматься одна и та же организация.
Все нижеизложенное было написано с точки зрения компаний деятельность которых не связана с информационными технологиями и ИТ рассматривается как инструмент увеличение эффективности основного бизнеса. На примере информационной системы, написанной с нуля или сильно кастомизированной под процессы компании.
Подразумевается, что компания доросла до осознания факта – всем по части компьютеров и информационных технологий не может заниматься один бородатый мужик в футболке с надписью «Админ шоколадки не пьет». Занимаясь всем, от заправки картриджей для принтера до администрирования серверов и написания кода на нескольких языках программирования.
Любое компьютерное приложение – это продукт. Как, например бумага. Она нужна в каждом офисе, но никто же не создает цехи по производству бумаги при каждом офисе. Ее просто покупают. Программный продукт так же должен закупаться у тех, кто его создает на профессиональной основе.
Вариант нанять одного или двух человек, которые все напишут – вообще не должен рассматриваться. Т.к. при таком раскладе качественно вести документирование вряд ли кто будет. И в случае ухода этих людей разобраться в том, как работает то, что они создали, будет очень сложно. А если говорить о системе, на которой построены процессы работы компании – то эта проблема становится бизнес и финансово критичной.
Нанять организацию предоставляющую услуги ИТ консалтинга передав ей полный ИТ суппорт бизнеса тоже не правильно.
Допустим, предприятию повезет, и в качестве подрядчика выберут профессиональную команду. Тогда они действительно все сделают – соберут требования, проведут анализ, напишут и внедрят продукт. Поставив весть бизнес в зависимость от них. Ведь кроме них никто не будет знать, как все это работает. Следовательно, нужна поддержка на постоянной основе. По цене, которую предложат они.
Просто ценой за поддержку никто не ограничится. Цены за развитие продукта значительно выше. А сделать так, что бы ваш бизнес всегда требовал развития и доработки их продукта для опытных людей не составит труда. А ведь наняли то профессионалов, не забывайте.
И еще, при таком сценарии они получают доступ к значительной части внутренней конфиденциальной информации компании. Да конечно будет подписано соглашение о неразглашении. Но думаю, не все согласятся доверить свою коммерческую тайну посторонней организации. Даже при наличии договора о неразглашении.
Они отдельная организация. И как в любой организации у них одна цель – заработать денег. Просто бизнес и ничего более.
По моему мнению – правильно разделить процесс разработки. Где анализ и постановка задач формируется внутри организации, а непосредственно разработка – передается подрядчику.
Для организации нормальной работы, как с подрядчиком, так и внутри организации, нужно создать команду. В самом простом случае я вижу в этой команде 4 роли. Плюс подрядчик как одна роль.
Менеджер (владелец системы)
Что делает
Определяет стратегию развития, в каком направлении развивается система, что будет нужно предприятию от этой системы через год, возможно два. Утверждает бюджеты. Отвечает за работу с подрядчиком в целом. Утверждает задачи подрядчику. Устанавливает приоритет по задачам.
Что не делает
Не является руководителем компании (руководитель должен максимально делегировать такие задачи на подчиненных, занимаясь целевым вопросами целевого бизнеса). Возможно заместитель или руководитель одной из функций. Но не ИТ. Не занимается вопросами, как развивать систему. Т.е. ставит задачу – нужно увеличить надежность хранения данных. Не затрагивая вопроса как собственно увеличить.
Характеристики
Человек, полностью понимающий основной бизнес компании. Имеющий большой опыт работы в разных функциях компании. Имеющий определенный авторитет и политический вес в компании. Административно не относится к структуре ИТ и не являющийся специалистом по ИТ технологиям.
Аналитик
Что делает
Описывает текущие процессы в компании в виде внутренних документов.
Разрабатывает и предлагает руководству оптимизацию существующих процессов и внедрение новых. Например, сейчас на составление одного договора с клиентом у продавца уходит 2 часа времени. В процессе анализа установлено что, если реализовать автоматическое составление и печать, то на подготовку договора будет уходить 2 минуты.
Превращает пространственные пожелания внутренних заказчиков в конкретный документ – бизнес требования. Отвечает за соответствие бизнес требований изначальным пожеланиям заказчиков.
Получает от подрядчика предложения по внедрению новых решений, продуктов и доработок. Анализирует насколько они необходимы компании. Если необходимы, предлагает руководству компании их внедрение.
Что не делает
Не принимает управленческих решений, только предлагает их. Не устанавливает приоритеты по задачам для подрядчика. В общих чертах разбирается в ИТ и поэтому не передает абсолютно нереализуемые идеи архитектору. В переговорах с подрядчиком не имеет права на собственное мнения – озвучивает только то, что согласовано с руководством.
Характеристики
Очень хорошо разбирается в процессах предприятия. Может предложить, как оптимизировать работу отдела или отдельного сотрудника, даже если сам сотрудник этого сказать не может. Поверхностно разбирается в ИТ технологиях. Важно что бы аналитик был своим, а не привлеченным со стороны подрядчика. Иначе это чревато развитием ради зарабатывание подрядчиком денег.
Архитектор
Что делает
Если менеджер определяет стратегию в каком направлении развивается система, то архитектор определяет как она развивается. Т.е. техническую сторону стратегии развития. Отвечает на вопросы типа, сколько серверов нужно привлечь для обеспечения работы системы при увеличении нагрузки, которую создадут 20 новых сотрудников, которых компания планирует привлечь в следующем году.
Пишет технические задания по предоставленным аналитиком бизнес требованиям и передает их подрядчику. Отвечает за соответствие технического задания бизнес требованиям.
Получает от подрядчика план работ по тех. заданию с оценкой трудозатрат. Анализирует предоставленный план на предмет завышения трудозатрат. В случае необходимости согласовывает с подрядчиком внесения правок. Утверждает план работ перед тем как его подпишет менеджер.
Проверяет предоставленный подрядчиком пакет на соответствие техническому заданию. Принимает участие в тестировании. Принимает решение о приемке работ и переносе изменений на основную среду.
В переговорах с подрядчиком должен иметь свою позицию в вопросах как это будет делаться. Но вопросы что делать определяет менеджер.
Что не делает
Не делает самостоятельные доработки системы. Не исправляет обнаруженные в процессе тестирования дефекты или несоответствия тех. заданию. Только уведомляет о них подрядчика. Не занимается администрированием или поддержкой приложения.
Характеристики
Должен обладать абсолютными знаниями по системе. А так же глубокими знаниями как технологий так и процессов ИТ в целом. Уметь вести переговоры, грамотно аргументировать свою точку зрения – от него зависит конечная цена работ и качество получаемого продукта.
Администратор
Что делает
Работает с пользователями. Заводить и удалять из системы, обнулять пароли. Консультировать по вопросам типа, что нужно нажать что бы открылась эта форма или почему неактивна та кнопка.
В установленные сроки реагирует на сбои и ошибки системы. Должен уметь перезапускать службы и перезагружать сервера. Выполнять другие шаблонные действия для поддержания или восстановления работоспособности системы. В случае аварий которые он не в состоянии решить, грамотно описать проблему и передает ее подрядчику в рамках договора о поддержке.
Устанавливать полученные от подрядчика пакеты на тестовую среду. Принимать участие в приемочном тестировании пакетов на тестовой среде. Устанавливать пакеты на основную среду после приемки работ.
Составляет паспорт, договор о предоставлении услуг пользователям и другие внутренние документы по системе.
Все действия которые может производить администратор должны быть описаны в «Руководстве администратора» которое составляет поставщик системы и поддерживает его актуальность после обновлений и доработок системы.
Что не делает
Не производит собственных доработок или изменений системы.
Характеристики
По сути, его работа это сплошная рутина. От него не требуется особых знаний. Должен выполнять пару десятков операций. Большинство из которых должны быть описаны в «Руководстве администратора». Но требуется внимательность стрессоустойчивость и ответственность.
Подрядчик (понятно, что со стороны подрядчика так же работает целая команда, но с точки зрения заказчика – они единое целое)
Что делает
Получает и анализирует техническое задание от архитектора. Предоставляет архитектору план работ с указанием трудозатрат своих менеджеров, аналитиков, программистов, тестировщиков. После согласования и уточнения плана, получает подписанный менеджером заказ на работы и оплату за работу аналитиков создававших этот план. Выполняет работы по согласованному плану. Предоставляет администратору пакет с изменениями и измененную версию руководства пользователя. После тестирования и подписания акта о приемке работ получает оплату.
Основываясь на своем опыте предлагает решения аналитику компании (и только аналитику).
Что не делает
Не занимается сбором требований и анализом процессов в компании. Любой анализ процессов со стороны подрядчика чреват решениями, которые не столько нужны компании, сколько должны принести доход подрядчику.
Не делает никаких предложений по системе никому кроме аналитика (по бизнес части) или архитектора (по технической части). Попытки «продать» какое либо решение бухгалтерам, маркетингу, продажам или кому то еще должны пресекаться с публичным наказанием виновных.
Не имеет доступа к основной среде. К тестовой среде – возможно, но без права внесения изменений. Вся разработка должна вестись на девелоперской среде.
Характеристики
Роль подрядчика должна сводиться к предложению решений на основе своего опыта аналитику компании и написанию кода по техническому заданию полученному от архитектора.
Пара слов о договорах
Между компанией клиентом и подрядчиком должно быть заключено два независимых договора.
Договор о поддержке. Описывает сроки предоставления решений по критическим авариям, которые не может решить собственный администратор и штрафы за нарушение этих сроков. Договор о поддержке – более дешевый. Им можно частично компенсировать убытки, понесенные из-за неисправности информационной системы (если до этого дойдет). Поэтому желательно, что бы он всегда был актуальным и своевременно перезаключался. Вместе с собственным администратором – это инструмент защиты бизнеса от ИТ-шных сбоев. В случае ухода собственного администратора временно можно полностью переложить задачи администрирования на подрядчика. В случае проблем с перезаключением договора о поддержке – есть собственный администратор который возьмет на себя полную поддержку системы пока договор таки не будет продлен на следующий период. В штатной ситуации должен быть и свой администратор и договор о поддержке.
Договор о развитии системы. Рамочный договор, который описывает порядок передачи заданий клиентом подрядчику, порядок приемки выполненных работ, оплат, решения спорных вопросов. Здесь же должны быть прописаны цены на услуги подрядчика. Например, стоимость единицы времени каждого ресурса подрядчика (аналитика, программиста и т.д.). Даже в случае его отсутствия это не влияет на текущую работу компании. Обеспечивая независимость бизнеса от подрядчика. Да, новых функций не будет, но хоть все текущие будут работать. В крайнем случае, можно будет объявить тендер на развитие системы и передать развитие другой организации. Документация по системе в компании есть, архитектор со своими знаниями тоже. Но это в самом крайнем случае, поддержкой и развитием должна заниматься одна и та же организация.
10.03.2012 19:34+0400