Як людина, яка не технічна, може навчитися писати специфіку для невеликих проектів?

Як людина, яка не технічна, може навчитися писати специфікації для невеликих проектів?

Мій друг намагається передати певні розробки на проект статистики.

Зокрема, він робить велику роботу у відмінність і хоче передати створення сценаріїв, щоб робити те, що він зараз робить вручну.

Однак мій друг надзвичайно нетехнічний. Він погано пише технічні характеристики.

Коли він пише специфіку, він пишеться так, як ви описали б робити щось в excel (перейдіть до цієї клітинки і потім скопіюйте значення в цю клітинку). Він також надмірно багатослівний і робить приклади кілька разів. Я не впевнений, чи правильно він описує кутові випадки.

Перший проект, який він передавав на аутсорсинг, був провальним. Я думаю, що він описав деякі деталі, але недоописав кутові випадки. Той та / або кодер, який він найняв, не роздумував над кутовими справами і не задавав відповідних питань. Я не впевнений. Я ввійшов до нього в чат, і мені знадобилося півгодини, щоб розкопати опис, який повинен був зайняти п'ять хвилин або менше. Я написав сценарії для нього наприкінці, але не вивчив, чому його процес із кодером не вдався.

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

Який правильний шлях до нього вчитися? Чи є ресурси, які він міг би використати? Чи є способи навчитися йому з невеликих практичних проектів низького тиску з кодерами?

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

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

Якщо ваш друг або буде просити створити численні програмні засоби або має намір укласти їх, він повинен навчитися писати вимоги до програмного забезпечення, принаймні на рівні бізнес-цілей та концепції операцій. Дві провідні книги щодо розробки програмних вимог - Карл Вігерс - Вимоги до програмного забезпечення (2-е видання) та Більше про вимоги до програмного забезпечення: Проблемні питання та практичні поради . Я б очікував, що більшість людей, яких він найме, захочуть якийсь документ, що описує систему, принаймні на рівні бізнес-цілей або концепції операцій, і ці книги беруться до цього. Вони також вивчають, як і чому інші аспекти проектування вимог, які, як я підозрюю, хороший розробник, пройдуть на початку проекту.

Другим варіантом буде або найняти когось із досвідом розробки програмного забезпечення та інженерії вимог (а можливо, навіть якоїсь інженерії систем чи архітектури системи), щоб зрозуміти проблемний простір та визначити, де потрібні програмні рішення та де програмні рішення не були б вигідно, пишіть документи і, можливо, навіть наглядайте або проводите зусилля з розробки. Однак це, ймовірно, буде дорожчим і коштує найняти штатного розробника програмного забезпечення на тривалий проміжок часу, щоб розробити не лише запитувану систему, але й необхідні вимоги та архітектуру.

Чесно кажучи, я не думаю, що переживає твій друг, - це рідкість для того, хто не розуміє процесу розробки програмного забезпечення. Я також не думаю, що провина повністю лежить на ньому. Якщо перший проект програмного забезпечення не мав належних вимог, розробник (ів), на які він передавав аутсорсинг, повинен був уточнити, уточнити та задокументувати вимоги. Чесно кажучи, я не впевнений, що ви є правильною особою для залучення, якщо ви не готові вкласти час або зусилля, щоб співпрацювати з нетехнічним користувачем / замовником і розробляти хороші технічні характеристики (це є ключовою роллю будь-кого, хто виконує вимоги щодо технічних вимог у будь-якій інженерній дисципліні).

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

Коли мені потрібні специфікації від нетехнічного клієнта, я зазвичай прошу їх написати простою мовою, що саме вони хочуть досягти. Як і в "додатку слід робити від A до B, коли я натискаю C, але тільки якщо D". Додатковий бонус за "тому що D означає, що ...".

Насправді "візьміть цей стовпець і проведіть середній показник по ньому". - це крок у правильному напрямку. Кращим поясненням було б "Таблиця містить це і те" (якщо структура заздалегідь визначена); "Отримайте середнє значення X". В основному, найменш можливий технічний спосіб без втрати деталей.

Іншими словами, опишіть ідею, а не реалізацію.

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

Якщо немає когось, хто достатньо піклується та розуміє процес, проект у будь-якому випадку провалиться.

Він може спробувати використовувати підхід до розкадрівки .

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

Він може використовувати такий інструмент, як Асана, щоб чітко визначити масштаби та функціональність проекту та навіть взаємодіяти зі своїм розробником.

Переклад її на чіткі вимоги - це в 10 разів більше роботи, ніж виконання чітко написаної специфікації.

Амінь. Це також пояснює, чому:

найманий ним кодер не продумав кутових справ і не задав відповідні запитання.

Розуміння вимог - найважча (і найдорожча) частина більшості програм програмування. Коли нетехнічна особа пише вимоги, вони часто лише документують обхід, який вони хочуть замінити ("відкрийте Excel, натисніть на комірку B3 ..."). Найкраще, на що вони можуть сподіватися, - це точний дублікат їхніх поточних труднощів!

Найбільш продуктивний спосіб, який я знаю, щоб подолати це, - це заохотити цю людину писати Use Cases ("використовувати" риму з "вільно"). Замість написання вимог опишіть, як система буде використовуватися. Це залишає розробнику деяку химерну кімнату, щоб запропонувати краще рішення, ніж те, що робить зараз користувач.

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

У будь-якому випадку, це звичайна і страшна труднощі, коли творчі люди або мають неповне уявлення, або нездатні описати його менше мільйона слів. Ця людина повинна намагатися знайти надзвичайно терплячого та проникливого програміста, який готовий дійти до глибини того, що вони насправді намагаються зробити і зробити це.

кодер, якого він найняв, не ... не задавав відповідних питань

Ось рецепт катастрофи. Це, а також очікування того, що кодер буде питати. Кодери люблять кодувати, а не спілкуватися, очікувати, що вони порушать свої звички без стимулу, досить нереально.

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

• Для ознайомлення надайте їм невеликі огляди ітеративних та методологій розвитку Agile (статті Вікіпедії), щоб вони зрозуміли, як це має бути.
   
• Щоб допомогти їм зрозуміти минулу невдачу, надайте їм легкий огляд Водоспаду / Великого дизайну на фронті (ті, що включають критику - знову ж таки, будуть зроблені статті Вікіпедії) - зазвичай вони роблять досить непогану роботу, пояснюючи, як зазвичай важко вказати речі правильно вперед спереду.

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

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

Це інакше - здається набагато простіше, ніж вказувати веб-додаток. Це логічний процес. Це найлегша штука.

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

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

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

Ваш друг повинен просто знайти потрібну людину. У будь-якому програмному проекті є потреба в аналітиках, програмістах, системних адміністраторах, тестерах та менеджерах проектів. Чим більше цих ролей ваш друг хоче «передати в аутсорсинг», тим кваліфікованішим буде провайдер і тим більше ваш друг повинен розраховувати платити.

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

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

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

Що стосується спілкування з нетехнічними людьми, важливо намагатися уникати використання жаргону комп’ютерів та розробки програмного забезпечення під час розмови з ними. Якщо вони використовують терміни жаргону з власного поля, то важливо зрозуміти, що означають ці терміни, щоб ви могли скласти глосарій проекту, щоб отримати формальні визначення для цих термінів. Адже ви працюєте над ними, тому важливо зрозуміти, звідки вони беруться.

замість жаргону слід спробувати скористатися не залякуючими способами спілкування зі своїм клієнтом, документи, написані простою англійською мовою, - це допомога, але багато людей у ​​бізнесі програмного забезпечення звикли писати для комп'ютерів, а не для людей, і тому вони можуть знайти це важко. Крім того, клієнти не люблять читати великі купи паперу, незалежно від того, наскільки зрозумілою є їхня мова, тому ви можете скористатися наочними посібниками. Діаграми, дротяні рами та дошки зручності тут є корисними інструментами.

Коротше кажучи, головний момент - це не робота вашого клієнта вивчати вашу мову, це ваше вивчити їхню мову.