Если вы уже приняли решение в проекте автоматизации обратиться за помощью к внешним специалистам и разработчикам, то это сообщение можно не читать! Данный текст посвящен тем смельчакам-"пионерам", кто выбрал тернистый путь самостоятельной разработки.
Я бы памятник воздвигла тем, кто смог реализовать все свои технические мечты и задумки, будучи не профильной IT организацией, в том виде, как задумывалось в проекте, и при этом уложившись более или менее (в приделах 15%) в бюджет и сроки.
Тем не менее, если вы только-только начали свой уникальный путь разработки, то наверное не будет вредным узнать о тех, подводных камнях, с которыми сталкивались другие, прошедшие данный этап проекта автоматизации. Но решать опять же вам, на сколько это интересно и полезно.
Итак, если у вас уже есть пакет проектной документации, выверенный и проверенный (а то и написанный) аналитиками, то пришло время переходить к следующему этапу реализации проекта автоматизации - передаче ТЗ и БТА программистам-разработчикам.
Что может быть проще - передать готовый пакет документации на разработку и спокойно ждать результата? Если бы так было возможно в действительности, это было бы сказкой, а не жизнью!
Все совсем не так. Программная реализация ТЗ это постоянное взаимодействие всех участников проектной группы - заказчика, аналитика, программистов и, при необходимости, организатора. Необходимость в регулярных коммуникациях обусловлена следующим: как бы не была хорошо продумана идея автоматизированного процесса, заранее учесть все нюансы невозможно - либо что-то не заметили, либо что-то успело измениться или устареть. В любом случае в процессе написания программы будут возникать вопросы у разработчиков и уточнения или дополнения у заказчика, когда он сможет визуализировать результаты своей задумки.
Поэтому, прежде чем приступать к разработке необходимо договориться о правилах взаимодействия:
1. Приемка и согласование промежуточных результатов
2. Фиксирование всех возникающих багов и хроники их исправления с итогами
3. Подача, приемка и отработка заявок заказчика на дополнительные доработки или внесение изменений, не учтенных в ТЗ
4. Правила апробации
5. Условия передачи системы в эксплуатацию
6. Распределение зон ответственности за результат
7. Правила и условия предоставления отчетности по разработке
8. Механизмы контроля за качеством разрабатываемой программы
9. Другое
Когда разработка передается внешним подрядчикам, то все условия оговариваются и регулируются заключенным договором на выполнение работ. В договоре указывается порядок и размер оплаты за выполненную услугу. Также в договоре закладываются действия в случае невыполнения взятых на себя обязательств - как со стороны провайдера - в виде штрафов и неустоек, а то и невыплаты вознаграждения. Доработки же оформляются в виде доп.соглашений с дополнительной оплатой и т.д. Успех автоматизации в этом случае во многом зависит от грамотно составленного договора - взаимодействие происходит на основании договорных соглашений.
Внутренняя разработка отличается тем, что обращаясь к другому подразделению в вашей организации сталкиваешься с определенными трудностями:
1. Расстановка приоритетов при разработке. Чтобы добиться автоматизации ваших процессов нужно доказать, что это важно и срочно, и имеет более высокий приоритет, чем у ваших коллег из других подразделений. Но даже если вам это удалось, не стоит расслабляться, приоритет нужно будет поддерживать на всем протяжении проекта - в любой момент может оказаться, что "ресурсов нет" и "есть более приоритетные задачи". В большей степени это касается сопровождающих функций, которые напрямую не обеспечивают прибыль компании, но тем не менее важны для общей работы организации, и которые не в меньшей мере трудоемки и рутины.
2. Внутреннее качество разработки сложно контролируемо. При оценке результатов и скорости выполнения работ вы не можете опираться на договор, только на ТЗ. Если при работе с внешним разработчиком, вы можете воспользоваться системой штрафов, неустоек или просто оплаты труда, то с коллегами все намного сложней, особенно если они получают зарплату, а проекты могут выбирать - что-то проще и быстрее, а что-то можно и подольше делать, так как з-п все равно платят.
3. Внутренняя клиентоориентированность ниже, чем внешних разработчиков. Это и понятно. Если у внешних организаций высокая конкуренция за клиентов (могут и отказаться и уйти к конкурентам), то от внутренних разработчиков никто не уходит - здесь всегда есть очередь и работа. Зачем договариваться с внутренним клиентом, если все равно придет к нему и будет просить повысить приоритет и выполнить задачу?
4. Сложности с технической поддержкой готового продукта. Любая программа требует обновления и развития. При чем постоянного обновления и развития. Но если вопрос приоритетов стоял на этапе разработки, то особо остро он будет стоять уже после сдачи в эксплуатацию. В отличие от внешних разработчиков, у кого это еще одна возможность заработать, у внутренних разработчиков такой потребности нет. Как отмечалось выше - там и так много работы.
5. Тестировщики часто оказываются в том же департаменте, что и разработчики. Поэтому есть вероятность, что ваши претензии не будут приняты в полном объеме, а повлиять на это крайне мало инструментов - зарплату платят, работы много (целая очередь), а тестировщики, даже если и увидят баги и недоработки, все же стараются "не обидеть своих".
Поэтому на входе, перед тем, как приступить к реализации нужно продумать все варианты взаимодействия, а также контроля и воздействия на разработчиков в случае, если работа выполняется некачественно или не в полном объеме.
Если с внешними разработчиками залогом качества является договор и дополнительные соглашения с указанием сроков выполнения работ и суммы оплаты, то с внутренними разработчиками также необходимо документировать все договоренности, достигнутые и достигаемые в процессе реализации проекта. Это может быть специальный регистр, который бы вы вели совместно, может быть электронная почта, где все сообщения ведутся (дублируются) в электронном виде, это могут быть протоколы встреч - письменные с подписью, либо электронные.. и так далее.
На мой взгляд, работать с внутренними разработчиками сложнее, но если есть цель достичь результата, то можно найти эффективные способы взаимодействия - главное, чтобы руководство поддерживало.
Что может быть проще - передать готовый пакет документации на разработку и спокойно ждать результата? Если бы так было возможно в действительности, это было бы сказкой, а не жизнью!
Все совсем не так. Программная реализация ТЗ это постоянное взаимодействие всех участников проектной группы - заказчика, аналитика, программистов и, при необходимости, организатора. Необходимость в регулярных коммуникациях обусловлена следующим: как бы не была хорошо продумана идея автоматизированного процесса, заранее учесть все нюансы невозможно - либо что-то не заметили, либо что-то успело измениться или устареть. В любом случае в процессе написания программы будут возникать вопросы у разработчиков и уточнения или дополнения у заказчика, когда он сможет визуализировать результаты своей задумки.
Поэтому, прежде чем приступать к разработке необходимо договориться о правилах взаимодействия:
1. Приемка и согласование промежуточных результатов
2. Фиксирование всех возникающих багов и хроники их исправления с итогами
3. Подача, приемка и отработка заявок заказчика на дополнительные доработки или внесение изменений, не учтенных в ТЗ
4. Правила апробации
5. Условия передачи системы в эксплуатацию
6. Распределение зон ответственности за результат
7. Правила и условия предоставления отчетности по разработке
8. Механизмы контроля за качеством разрабатываемой программы
9. Другое
Когда разработка передается внешним подрядчикам, то все условия оговариваются и регулируются заключенным договором на выполнение работ. В договоре указывается порядок и размер оплаты за выполненную услугу. Также в договоре закладываются действия в случае невыполнения взятых на себя обязательств - как со стороны провайдера - в виде штрафов и неустоек, а то и невыплаты вознаграждения. Доработки же оформляются в виде доп.соглашений с дополнительной оплатой и т.д. Успех автоматизации в этом случае во многом зависит от грамотно составленного договора - взаимодействие происходит на основании договорных соглашений.
Внутренняя разработка отличается тем, что обращаясь к другому подразделению в вашей организации сталкиваешься с определенными трудностями:
1. Расстановка приоритетов при разработке. Чтобы добиться автоматизации ваших процессов нужно доказать, что это важно и срочно, и имеет более высокий приоритет, чем у ваших коллег из других подразделений. Но даже если вам это удалось, не стоит расслабляться, приоритет нужно будет поддерживать на всем протяжении проекта - в любой момент может оказаться, что "ресурсов нет" и "есть более приоритетные задачи". В большей степени это касается сопровождающих функций, которые напрямую не обеспечивают прибыль компании, но тем не менее важны для общей работы организации, и которые не в меньшей мере трудоемки и рутины.
2. Внутреннее качество разработки сложно контролируемо. При оценке результатов и скорости выполнения работ вы не можете опираться на договор, только на ТЗ. Если при работе с внешним разработчиком, вы можете воспользоваться системой штрафов, неустоек или просто оплаты труда, то с коллегами все намного сложней, особенно если они получают зарплату, а проекты могут выбирать - что-то проще и быстрее, а что-то можно и подольше делать, так как з-п все равно платят.
3. Внутренняя клиентоориентированность ниже, чем внешних разработчиков. Это и понятно. Если у внешних организаций высокая конкуренция за клиентов (могут и отказаться и уйти к конкурентам), то от внутренних разработчиков никто не уходит - здесь всегда есть очередь и работа. Зачем договариваться с внутренним клиентом, если все равно придет к нему и будет просить повысить приоритет и выполнить задачу?
4. Сложности с технической поддержкой готового продукта. Любая программа требует обновления и развития. При чем постоянного обновления и развития. Но если вопрос приоритетов стоял на этапе разработки, то особо остро он будет стоять уже после сдачи в эксплуатацию. В отличие от внешних разработчиков, у кого это еще одна возможность заработать, у внутренних разработчиков такой потребности нет. Как отмечалось выше - там и так много работы.
5. Тестировщики часто оказываются в том же департаменте, что и разработчики. Поэтому есть вероятность, что ваши претензии не будут приняты в полном объеме, а повлиять на это крайне мало инструментов - зарплату платят, работы много (целая очередь), а тестировщики, даже если и увидят баги и недоработки, все же стараются "не обидеть своих".
Поэтому на входе, перед тем, как приступить к реализации нужно продумать все варианты взаимодействия, а также контроля и воздействия на разработчиков в случае, если работа выполняется некачественно или не в полном объеме.
Если с внешними разработчиками залогом качества является договор и дополнительные соглашения с указанием сроков выполнения работ и суммы оплаты, то с внутренними разработчиками также необходимо документировать все договоренности, достигнутые и достигаемые в процессе реализации проекта. Это может быть специальный регистр, который бы вы вели совместно, может быть электронная почта, где все сообщения ведутся (дублируются) в электронном виде, это могут быть протоколы встреч - письменные с подписью, либо электронные.. и так далее.
На мой взгляд, работать с внутренними разработчиками сложнее, но если есть цель достичь результата, то можно найти эффективные способы взаимодействия - главное, чтобы руководство поддерживало.
Если вам интересна тема автоматизации бизнес-процессов заказчика, подписывайтесь, чтобы получать уведомления о продолжении.
Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!
To be continued...
Всегда ваша
Денисова Елена,
Комментариев нет:
Отправить комментарий