Основи розробки ПЗ: добре сформульована мета
Андрей ХаврюченкоОпубликовано 13.12.2006 в Статьи
Враховуючи сорокарічну історію індустрії розробки програмного забезпечення, жаль що так небагато розробників розуміють базу, психологічний фон своєї роботи.
В цьому можна пересвідчитись не тільки перевіривши живу статистику успішності програмних проектів (половина проектів або відміняється або вилазить за первісні межі), але й просто поспілкувавшись з сусідами по кімнаті, співробітниками, студентами.
Я веду курс з розробки програмного забезпечення і тільки половина моїх студентів на першій, установчій, лекції дає правильну відповідь на питання
З чого Ви почнете проект з розробки ПЗ?
І це навіть в найпростішій моделі проекту: один замовник - один розробник…
Ну добре, мої студенти - не зірки МІТ-у або КалТеху, але половина!?..
Проект з розробки ПЗ - це проект. За визначенням
Вікіпедії та PMI це означає, що:
- у нього є початок
- у нього є кінець і
- він пов’язаний зі створеннямcreation of чогось
Іншими словами, у кожного програмного проекта є мета.
То чому ми не використовуємо методи психології, які публічні і давно доступні, як допомогу в цьому процесі досягнення мети?
В психології особистості, досягнення мети - одна з найбільш розроблених частей. Фактично, все наше життя - це процес досягнення цілі, що складається з цілей меншого масштабу.
Між досягненям і недосягненням мети є, м’яко кажучи, помітна різниця. І якщо мене цікавить як виконати мій проект, натуральним є питання
Які необхідні компоненти цілі, що можна досягти?
Та це ж елементарно! “Not a rocket science”, пустити гугл шукати “well formed goal” (добре сформульовану мету). На момент написання англійського варіанту цієї статті, гугл видає статтю Вікіпедії”Well formed outcome” третьою.
Основними критеріями добре сформульованої мети є:
- Позитивність. Це означає що будь-який проект, метою якого є, скажімо, “недопуск спаму і вірусів на комп’ютер” є одразу приреченим на невдачу. Ніхто просто не в стані досягти небуття чого-небуть точно так же як і довести негативне твердження. Для перевірки, доведіть що ви не п’єте коньяк вранці.
- Конкретність. Це найважливіша властивість хорошої мети в програмному проекті. Знайте що Ви побачите, почуєте, відчуєте коли досягнете мети (наприклад певна функція ПЗ буде працювати корректно). Будьте настільки конкретними, наскільки Ви можете. І навіть більше. Використовуйте всі сенсорні системи для визначення вашої мети. Неконкретність - перша причина зриву в досягненні цілі.
- Бути можливою і досяжною. Можна вважати, що практично будь-яка (корисна) мета - досяжна. Та на практиці цей критерій насамперед означає, що Ви, той хто прагне досягти цієї мети, вважаєте її можливою та досяжною. Прямо тут і зараз. Цей критерій пов’язаним з наступним:
- Наявність всіх ресурсів. Майте комп’ютре, майте інтернет-з’єднання, майте електрику та волю для виконання проекту, знайте та умійте те, що треба, якісно спілкуйтесь з Замовником, і т.д., і т.п. Майже будь-що можна вважати ресурсом (включаючи перелік цих критеріїв), що Вам доступен або не доступен. З мого досвіду, недостатні ресурси - друга за частотою причина недосягнення мети.
- Добре окреслений часовий проміжок. Ні, пане Замовнику це має бути готово на вчора не являється добре окресленим часовим проміжком.
- Екологічність. Ви, хто працює над досягненням результату, знайте чого він буде коштувати і що за собою потягне. Так, отримати мілліон внаслідок грабунку банку може бути добре сформульованою метою. Але тільки якщо Ви приймаєте ціни та наслідки такої поведінки. Я - ні.
Весь механізм досягнення добре сформульованих цілей забезпечується самою природою. Мозок людини, від кори до спинного мозку налаштований на досягнення цілей. Вся еволюція від бактерії через трилобітів до homo sapiens - це процес успішного досягнення цілей. Ті, хто не досягав мети - зходив з дистанції. Його з’їдали. Так що буквально кожна людина (я не знаю нелюдських розробників ПЗ, якщо вам такі відомі - дайте знати) має всередені виключно потужний механізм досягнення будь-якої мети.
Для мене, програмний проект - це кампанія по перекладу. Розробник перекладає ідеї Замовника на машинну мову. Критерії, окреслені вище - всього навсього інструкції для перекладу нечітких намірів в щось що наша підсвідомість розуміє і звична до виконання.
То чому б реально не зробити перший крок для досягнення мети - добре її визначити?
Англійський варіант Software Development Basics: Well-Formed Outcome
(4 голосов, средний: 4.75 из 5)
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
Recommended reading about the same: http://www.amazon.com/Discovering-Business-Requirements-Software-Computing/dp/1580537707
http://trenings.ru/content/view/360/59/
Хорошая статья, интересно читать. И чувствуется, как автор прямо подпрыгивает от возбуждения, стараясь передать нам хоть часть своего понимания и видения.
Единственный минус, который меня беспокоит - оторванность от практики. Да, это хорошая теория, я с ней соглашаюсь и принимаю, но щас мне предстоит делать новый проект, и как конкретно, по-другому, более качественно надо будет ставить и достигать цели?
Пардон: ссылка, предоставленная ili, устраняет недостаток отсутствия практики. Спасибо!
Олександр, дійсно, я щойно прокинувся і аж підстрибую від бажання.
Правда, від бажання випити кави, а не кидатись передавати вам “щось”. Навіть частину
Власне відповідаючи на питання, можу запропонувати сходити по посиланню на англійську версію статті, знайти контакти і кинути лист з проханням провести ту ж саму вступну лекцію, яку я даю студентам свого курсу.
Або почекати доки будуть опубліковані подальші статті, що описують весь комплекс базових інструментів розробки: (а) добре сформульовану мету (б) декомпозицію (в) аналіз (той що After Action Review).
А потім - тільки практика. Ніяки тренінги та посилання не допоможуть при її відсутності.
Ili, я ж сказав що це добре відома тема
Тільки чомусь добре відома != широко застосовувана.
Всё понятно, буду ждать статьи.
Кстати, этим “подпрыгивает от возбуждения” я хотел сказать, что прямо чувствуется, как интересна тема автору, а не физические ужимки перед клавиатурой, как ты подумал. К тому же ты уже не можешь не передать - статья написана и опубликована.
Олександр: зрозумів, просто знай що таке словосполучення має і інші інтерпретації і не факт, що твій співбесідник зрозуміє саме так, як ти хотів
Стосовно “цікава”.. Це м’яко сказано
Намагаючись з 1998 року спокійно спати доки мої продукти працюють “десь” я не міг не прийти до певного процесу і філософії розробки. В сфері чуттєвого досвіду (побачити, почути, помацати) це в 2003 році вилилось в тренінг з основ розробки ПЗ. Тепер, по досвіду тренінгу - статі.
Повторювати майже слово-в-слово кожному студенту за майже 4 роки набридає
Є квола надія що статтями середній рівень розробників хоч трохи підніметься.
Удачі в розробці!
Предлагаю изменить отношение к задаче.
Пример: (лекция->тренинг) => (известность->примениние)
//тренинги проводил. опыт есть )
//лекции тоже )
http://www.developers.org.ua/archives/motus/2006/10/28/kuda-poyti-uchitsya/#comment-8697
http://nkozlov.ru/syntone/syntone20/
Пропоную, до купи, додати в коментарі ще лінки на загальну психологію людини та тренінг ЕСТ
уж лучше почитать http://research.rbc.ru/rev_short/24364319.shtml
Ili: кому краще?
Якщо ти вважаєш що мені краще, то будь-ласка поясни свою думку докладніше. Я свій курс не продаю і він бізнес-тренінгом не являється. Він взагалі не є тренінгом, а навчальним курсом.
Отже?
Ili, отримав коментар поштою, але тут його ще не бачу.
Пропоную в пошту і перенести, бо я знову не бачу кому ти пропонуєш. Відсутній суб’єкт. Переформулюй будь-ласка.
Ok.
Ушло
2Mods - предлагаю всю личную преписку в dev/nyll …
2akhavr - ты таки продаешь … вопрос чем платить …
Ili: і що ти хочеш мені продати?
Не вдаючись до грунтовного аналізу Вашої роботи вбачємо у Вашій особі спеціаліста у сфері планування людської діяльності.
На нашу Думку ситуацію в Україні може змінити тільки правильно сформулювана президентська Програма Спільних дій.
Пропонуємо наш проект Програми та “Окреслення шляху” до неї.
http://kpk.org.ua/2007/05/28/teror_korupcja_rejjderstvo_ta_bagatopartjjnst.html
В разі зацікавленості матеріал буде надісланий на запит.
З повагою Микола Дмитренко.
Запрошуємо до участі в розробці та реалізації національної мети Української Духовної Республіки - Програми дій.
Я не погоджуюсь з приведеним прикладом.
Наприклад поставимо позитивну ціль - “забезпечення стабільної роботи системи та цілісності даних та отримання бажаною пошти”.
Ця ціль не може бути конкретною, бо її можна трактувати по різному. А наприклад приведена вами “негативна” - є досить однозначною. Можливо приклад не вдалий, але все ж таки. Коли переді мною стоїть задача, більш важливим є однозначне тлумачення даної проблеми.
Сучасні новомодні психології багато приділяють цьому уваги. І думаю, що це актуально для життєвих цілей, але не для постановки завдання при розробці ПЗ. Тут більш важлива Конкретність.