Как да разработим Техническо задание
След като помислих внимателно, реших, че няма да работи отново да събера целия материал от планираната втора част в една статия, в противен случай ще бъде върхове и на теория, което вече е написано в много учебници. Но все пак си поставих задачата, така че това да се приложи на практика, така че вече няма да мисля за в бъдеще колко проблеми ще трябва да свърша с темата. Това също ще бъде повлияно от обратната връзка от читателите, така че пишете, не се срамувайте!
Използвайки тази възможност, искам да задам въпрос: колко интересно би било да се организира практически обучителен семинар в Санкт Петербург за разработването на Техническото задание? Ще се срещаме и ще обменяме опит. Ако такъв интерес не е единичен, обещавам да организирам.
Тъй като читателите са не само специалисти в областта на разработката на софтуер, но и бизнес анализатори и мениджъри от различни нива, ще се опитам да пиша по начин, който би бил интересен за всички.
В тази част ще говорим за това как да организираме етапа на работа по събиране на изисквания, от какво трябва да се състои и какви инструменти могат да се използват. Повтарям, че тези работи по етапи са много подобни на проучване на предприятието, за да се опишат бизнес процесите.
Както обикновено в живота:
Както се случва в повечето проекти
Стъпки
Как се случва
Защо има такава практика, както е описано по-горе? Признавам си, че не знам. Никой не пита, никой не знае. В същото време ситуацията не се променя много бързо, въпреки че тази тема непрекъснато се обсъжда, обменя се опит, пишат се книги ... Струва ми се, че една отпричини - ниското качество на съответното образование. Може да се повлияе и от факта, че много специалисти идват от съвсем други бизнеси и разбират всичко на практика, т.е. техният опит се формира от средата, в която се намират. Отношението на университетите и липсата на желание да бъдат по-близо до реалността също е всеизвестен факт, но понякога позицията им ме изненадва. Например, имах случай, когато студентка, талантлив специалист, искаше да напише дисертация на платформата 1C (добро развитие на индустрията), но в катедрата й беше казано, че независимо от темата е невъзможно да разчита на „отлична“ оценка, т.к. 1C не е сериозна система. Въпросът тук не е сериозността и обективността на такова мнение, а фактът, че примитивна задача на класически език за програмиране веднага се счита за достойна за „отлична“ оценка.
Нека се опитаме да дадем по-систематичен подход на процеса, обсъден по-горе. Как може да изглежда тогава?
Както можете да видите, процесът завършва с въпрос, т.к по този въпрос работата далеч не е приключила и тогава ще започне най-трудното и най-практичното - точно това, което ще определи приложимостта на получения резултат в реалния живот. Точно това ще определи съдбата на предишната творба: или ще отиде в килера (на рафт или някъде другаде), или ще бъде ценен източник на информация. И още по-добре, ако стане модел за бъдещи проекти.
Нека да видим как можете да реорганизирате подхода за събиране на информация за дейността на компанията.
Как може да стане това при по-компетентна организация на работа