У сфері розробки програмного забезпечення для управління ресурсами підприємства зі складними способами перетворення виробничих завдань в програмний алгоритм не обійтися без розробки технічного завдання. По суті, від правильності складання завдання на проект залежить підсумок роботи групи розробників: чи видадуть вони «на гора» працездатну систему, або при досвідченої експлуотаціі виявиться, що не врахована контур роботи одного з департаментів підприємства і весь проект доведеться переробляти. Для того щоб мінімізувати трудовитрати програмістів з написання коду, грошових коштів і часу рекомендується дуже відповідально поставитися до підготовки передпроектної документації. За оцінками експертів трудовитрати на підготовку передпроектної технічної документації складають близько 15% часу розробки самого проекту. Ще 65% іде на саму розробку і останні 20% на тестування і введення в експлуотацію програмного продукту. У ході робіт будуть, звичайно, уточнюватися мети або додаткові технічні нюанси, але краще з самого початку визначити із замовником головні вектори впровадження. Для правильного формулювання мети технічного завдання потрібно визначиться з відповідальною особою, яке буде ставити завдання. Це можуть бути люди, безпосередньо пов'язані з виробничими завданнями, і надалі використовують розроблені рішення або керівники підрозділів. Зрозуміти як саме повинна запрацювати проектована бізнес-система розробнику важко лише на підставі кількох технічних подробиць. Для повноти охоплення і логічного розуміння важливо розібратися в суті роботи підприємства. Тому замовнику, визначального мета проекту, дуже важливо пояснити не тільки бажані технічні тонкощі написання коду або оформлення форм додатків, а поверхнево (без розкриття комерційної таємниці) ознайомити внедренцев-проектувальників з бізнес-діяльністю підприємства. Крім того на стадії планування проекту важливо визначиться з термінами, які виділяються засобами і кількість штату команди для розробки.

Класичне технічне завдання складається з:

  1. Описи діяльності підприємства, його структурних підрозділах;
  2. Розкриття інформаційної політики, принципи доступу до даних, зберігання баз даних, рівні доступу користувачів;
  3. Встановлюються контури впровадження за видами виробництва. Виводяться списки використовуваних документів, форм, звітів;
  4. Інші додаткові доопрацювання, які не відносяться до основного впровадженню; Ролі користувачів, інструкції для персоналу;

 По суті, технічне завдання може носити і довільну форму залежно від масштабів проекту. Якщо це стосується доопрацювань невеликої ділянки модуля або форми документа, всіх пунктів в такому випадку технічне завдання включати не буде. І навпаки, якщо ERP-система проектується з нуля, то документація може бути розширена. Як правило, фірми займаються підготовкою передпроектної документації використовують стандарти в підготовці технічних завдань і воліють пройтися з замовником по всіх пунктах отримавши від замовника відповідь «ні» на запитання, ніж в середині виконання проекту виявиться що якась деталь у розробці не враховано. Важливо те, щоб технічне завдання було затверджено з обох сторін. Як з боку замовника так і з боку виконавця. Т.к. з практичної точки зору сам проект на папері - це по суті договір між сторонами і в ході роботи обидві сторони мають право звертатися до документації для доказу правоти своїх вимог як до проекту (замовник) так і до розробки (виконавець).

Такі ось складні технічні, практично юридичні аспекти питання підготовки проектного менеджменту ховаються здавалося б за банальними вимогами до розробки інформаційної системи.

Консультант з впровадження 1С

УКРАЇНА
61000 м. Харків, пл. Повстання 7/8, 
  +38(050)978-88-74
  +38(057)761-99-01
   Ця електронна адреса захищена від спам-ботів. вам потрібно увімкнути JavaScript, щоб побачити її.

Консультант з обслуговування 1С

УКРАЇНА
61000 м. Харків, пл. Повстання 7/8, 
  +38(066)131-75-25
  +38(057)761-99-01
   Ця електронна адреса захищена від спам-ботів. вам потрібно увімкнути JavaScript, щоб побачити її.