ფუნქციონალური არქიტექტურა წარმოადგენს სისტემის ფუნქციის დეტალურ აღწერას და სტრუქტურას, რომელიც შექმნილია ტექნოლოგიური, მომხმარებლის და ბიზნესის მოთხოვნებით, აგრეთვე ფუნქციების იერარქიის, მათი ერთმანეთთან დამოკიდებულებისა და ამ სისტემის კომპონენტებში გამოყენების გათვალისწინებით.
რატომ გამოჩნდა ფუნქციონალური არქიტექტურა და რა ამოცანებს ხსნის იგი?
ციფრული პროდუქტების შექმნის პროცესში იმალება ერთი სერიოზული ხარვეზი, რომელიც ეხება რისკების გადანაწილებას:
მოდით, ეს პროცესი დავყოთ ორ ძირითად მიმართულებად:
1) პროდუქტის დიზაინი (კვლევა, ანალიტიკა - პროექტირება, დიზაინი)
2) დეველოპმენტი (კოდირება და ტესტირება). ზოგიერთ შემთხვევაში დამპროექტირებლები თავიანთ დაკისრებულ მოვალეობებს გადასცემენ დეველოპერებს. დეველოპერები იძულებულნი არიან მიიღონ გადაწყვეტილებები და ეძებონ პასუხი ისეთ კითხვებზე, რომელიც მათ საერთოდ არ უნდა ეხებოდეთ. (კლასიკური მომენტი): "რა მოხდება, თუ სოციალურმა ქსელმა არ დაუბრუნა მომხმარებლის ელ.წერილი?" ან: "საჭიროა ამ შეცდომის შესახებ შევატყობინოთ მომხმარებელს?"
ასე რომ, ფუნქციური არქიტექტურა ზუსტად შექმნილია რისკების შესამცირებლად. მოახდინოს დეველოპმენტის სტაბილიზაცია გარკვეულ ეტაპზე და წინასწარ იპოვოთ კითხვაზე პასუხები მნიშვნელოვან ნაწილში. ნუ აიძულებთ ჩვეულებრივ დეველოპერებს მიიღონ არქიტექტურული და UX თან დაკავშირებული გადაწყვეტილებები.
როგორც წესი დეველოპერი ფიქრობს მხოლოდ პროექტის იმ ნაწილზე, რომელზეც ამჟამად მუშაობს. იგი მთლიანობაში ვერ აფასებს პროდუქტს, და არ ინახავს მას მთლიანად თავში. მერწმუნეთ, მათ გაცილებით მეტი საზრუნავი აქვთ :).
ამიტომ შეეცადეთ დაადგინოთ ყველა საერთო ფუნქცია დაპროექტების და დიზაინის ეტაპზე რომ შემდგომ ეს ყველაფერი პირდაპირ მიუთითოთ პროგრამისტს.
პროექტი რომელიც იქმნება ფუნქციუნალური არქიტექტურის გარეშე რთულია მისი შენარჩუნება და განვითარება (ესეთ პროექტს MVP ზეც ვერ გაუშვებთ ადეკვატურად წინ ბევრი პრობლემა დაგხვდებათ, ამის თაობაზე ვრცლად კიდე სხვა დროს ვილაპარაკებთ). ამ დროს კოდი ძალიან სწრაფად დეგრადირდება, და როგორც წესი ადანაშაულებენ უდანაშაულო დეველოპერებს :) .
ფუნქციური მოთხოვნები
ფუნქციონალური მოთხოვნები და ფუნქციონალური არქიტექტურა განსხვავდებიან ერთმანეტისგან. როდესაც ანალიტიკოსი აგროვებს ფუნქციონალურ მოთხოვნებს, ის ქმნის ამოცანებს, სტრუქტურირებული აღწერილობის შესახებ, და პირდაპირ დეველოპერებისთვის ასეთი მოთხოვნის გადაცემა არაა სწორი და გამართლებული.
დამპროეტქებლებს ისევე, როგორც დეველოპერებს, გაცილებით სრულყოფილი და ყოვლისმომცველი ინსტრუქციები სჭირდებათ.
F.A. უნდა იყოს მოქნილი და არ იყოს რთული. წინააღმდეგ შემთხვევაში თქვენ ხშირად მოგიწევთ უკან დაბრუნება და აღწერილ ფუნქციების განახლება. საწყის ეტაპზე მნიშვნელოვანია ძირითადი საკვანძო სცენარების ჩამოყალიბება, რომ დადგინდეს პროდუქტის ძირითადი მექანიკა, ამ ყველაფრის გათვალისწინებით შესაძლებელია პროდუქტი გაეშვას ადრეულ სტარტზე, რაც თავის მხრივ ამცირებს დაპროექტირების დროს და გაძლევთ საშუალებას უფრო ღრმად შეიგრძნოთ პროდუქტის არქიტექტურა.
განვიხილოთ მოკლე ეპიზოდი: მაგალითად პროდუქტის დასამუშავებლათ მნიშვნელოვანია დავყოთ იგი მოდულებად და დავშალოთ ნაწილებად, რომ მკაფიოდ გავიგოთ მათი დანიშნულება ყოველ იტერაციაზე სადაც უნდა იყოს გათვლილი ყველა შესაძლო ნაბიჯი, ამ დროს მთავარია, კარგად გაერკვიოთ ბიზნეს მოდელში ანალიტიკოსთან ერთად, რათა სწორად მოვახდინოთ დიზაინ პროცესების ადაპტირება.
F.A. გულისხმობს დამპროეტქებლებისთვის და პროგრამისტებისთვის სრული და ღრმა დიზაინ პროცესების აღწერილობის სისტემის გადაცემას - სადაც იქნება მკაფიოდ წარმოჩენილი მნიშვნელოვანი მომენტი, ასეთი მიდგომა აჩქარებს დეველოპმენტის პროცესს და ხდის იოლად სამართავს...
#დიზაინი
#ux