Правила оформлення «Заявки на створення програмного продукту»

Раніше ми писали Навіщо потрібна «Заявка на створення програмного продукту». Тепер давайте поговоримо про те, як заповнити її і що слід вказати в ній, а що ні.

При формуванні заявки виконавцю на доопрацювання важливо:

Розуміння кінцевого результату доопрацьованих механізмів.

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

Структурувати інформацію.

Розписати детально заповнення кожного поля звіту, друкованої форми. Які є відбори і умови щодо заповнення. Найчастіше замовник пише тільки пряме заповнення, і не передбачає варіанти заповнення «А як заповнювати якщо ...?». А на питання:

- Як заповнювати якщо буде така-то ситуація?

Завжди у відповідь чуєш:

- Це вкрай рідко буває. Майже ніколи.

- Ok. Не питання. Тоді якщо буде така ситуація програма буде не коректно працювати. Вас це влаштовує?

- Ні.

- Тоді скажіть як заповнювати.

- А я не знаю, придумайте самі. Ви то краще знаєте програму ....

Ось і починається з'ясування бізнес-процесів замовника, його структури та принципів роботи для того, щоб написати заявку на маленьке доопрацювання, тому що замовник насправді не знає чого хоче. Знає тільки якою має бути «Картинка». Найчастіше, час, витрачений на оформлення заявки більший ніж на саме написання коду.

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

Призначати особу, відповідальну за якість виконання заявки та строки перевірки виконаної роботи.

З боку замовника завжди має бути відповідальна особа, яка перевірить виконання заявки, протестує її у всіх можливих ситуаціях і дасть згоду на прийняття робіт. Це важливо з тієї причини, що розробка програмних рішень по заявці замовника теж має гарантійні терміни. Якщо протягом, наприклад, 5 днів від замовника не надійшло заперечень за якістю виконаних робіт, то роботи вважаються прийняті. Тому що бувають ситуації, коли замовник оформив заявку, все зробили по ній і встановили. Замовник працює пів року, а потім наприклад, звільняється співробітник який працював з цим доопрацюванням і новий співробітник пише виконавцю «Все пропало ....». Нічого не працює, або працює не так як потрібно, а як потрібно ніхто не знає. Тому повинен бути відповідальний який в короткі терміни, поки всі пам'ятають в чому суть заявки і що по ній зроблено перевірить її виконання і дасть підтвердження або додаткові побажання.

  Ціна питання.

Перед оформленням заявки замовник повинен для себе розуміти ціну, яку він готовий заплатити за свої бажання. Він не завжди має розуміти ланцюжок формування ціни, як ми не замислюємося чому зубна щітка коштує наприклад 30 грн, і скільки в її вартості торгової націнки, розмитнення, доставки, зарплати касира ... . Так і тут, замовнику не обов'язково знати всі процеси формування витратної частини і які прямі і непрямі витрати входять у вартість. Йому для розуміння навіть попередньої вартості необхідно розуміти основні етапи, які проходить його заявка. це:

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

Ось так, здавалося б, скільки коштує додавання якоїсь друкованої форми, там робіт на пів години, додати тільки одне поле(з точки зору замовника). А якщо припустити хоч один пункт, то робота буде виконана неякісно, ​​а це рівносильно що просто не виконана. Якби Ілон Маск не дотримувався правил прописаним його науковим відділом, а робив те що хочуть інвестори, з їх слів, то Тесли зараз не тільки в космосі, але і на землі не було б.

Так, ці всі правила здорожують виконання робіт, але люди їздять вже не на «Жигулях» і автомобілі ремонтують не в домівках кожен сам. Адже трохи інші швидкості, і розумієш, що якщо сам надумаєш відремонтувати автомобіль, то можеш в самий невідповідний момент «злетіти з дороги». Все частіше їдемо на перевірені СТО, а не до «Дяді Васі». Так і програмне забезпечення, це не «Жигулі», це зовсім інший рівень, але все ще є ті, хто з сучасного програмного забезпечення хоче зробити «Жигулі».

Зараз читають - "Безконтактне спілкування - новий тренд в автоматизації бізнесу"

Починаючи від елементарного, від правил роботи по заявкам і закінчуючи великими розробками ми вивели рівень роботи наших фахівців на такий рівень, що тільки наші розробки GES ЗЕРНО КОРП и СОФТІНФОРМ. ERP УПРАВЛІННЯ ОЛІЙНОЕКСТРАКЦІЙНИМ ЗАВОДОМ єдині, які отримали сертифікати "сумісно з програмами BAS". А це означає що вони відповідають усім вимогам розробника. І якщо замовник хоче, щоб його програмне рішення спрощувало йому життя, а він не чекав, коли і що перестане працювати, тому що він знайшов дешевше, і при цьому відповідало всім нормам, він йде до нас, а не до тих, хто робить « заплатки », ставить « милиці » і « пише на коліні ».

Ось такі важливі правила оформлення, здавалося б, такого не важливого документа.