სამუშაო პროცესის ორგანიზება გუნდში IT პროექტზე

გამარჯობა მეგობრებო. საკმაოდ ხშირად, განსაკუთრებით აუთსორსინგში, იგივე სურათს ვხედავ. გუნდებში მკაფიო სამუშაო პროცესის ნაკლებობა სხვადასხვა პროექტებზე.

ყველაზე მნიშვნელოვანი ის არის, რომ პროგრამისტებს არ ესმით, როგორ დაუკავშირდნენ მომხმარებელს და ერთმანეთთან. როგორ ავაშენოთ ხარისხიანი პროდუქტის განვითარების უწყვეტი პროცესი. როგორ დაგეგმოთ თქვენი სამუშაო დღე და სპრინტები.

და ეს ყველაფერი საბოლოოდ იწვევს გამოტოვებულ ვადებს, ზეგანაკვეთურ სამუშაოებს, მუდმივ დაპირისპირებას იმის შესახებ, თუ ვინ არის დამნაშავე და კლიენტების უკმაყოფილება, სად და როგორ მიდის ყველაფერი. ხშირად ეს ყველაფერი იწვევს პროგრამისტების, ან თუნდაც მთელი გუნდის შეცვლას. მომხმარებლის დაკარგვა, რეპუტაციის გაუარესება და ა.შ.

ოდესღაც ისეთ პროექტზე მოვხვდი, სადაც ყველა ეს სიამოვნება იყო.

არავის სურდა პროექტზე პასუხისმგებლობის აღება (დიდი სერვისის ბაზარი), ბრუნვა იყო საშინელი, მომხმარებელი უბრალოდ მოწყვეტილი და იმედგაცრუებული იყო. აღმასრულებელი დირექტორი ერთხელ მოვიდა ჩემთან და მითხრა, რომ თქვენ გაქვთ საჭირო გამოცდილება, ასე რომ, აქ არის ბარათები თქვენს ხელში. მიიღეთ პროექტი თქვენთვის. თუ გააფუჭებთ, ჩვენ დავხურავთ პროექტს და ყველას გამოვტოვებთ. გამოვა, მაგარი იქნება, მერე წარმართე და ისე განავითარე, როგორც შენ გგონია. შედეგად გავხდი პროექტის გუნდის ლიდერი და ყველაფერი ჩემს მხრებზე დაეცა.

პირველი, რაც გავაკეთე, იყო ნულიდან სამუშაო პროცესის შემუშავება, რომელიც შეესაბამება ჩემს იმდროინდელ ხედვას და დავწერე სამუშაოს აღწერა გუნდისთვის. მისი განხორციელება ადვილი არ იყო. მაგრამ დაახლოებით ერთ თვეში ყველაფერი მოგვარდა, დეველოპერები და კლიენტი შეეჩვივნენ და ყველაფერი მშვიდად და კომფორტულად წავიდა. იმისათვის, რომ გუნდს მეჩვენებინა, რომ ეს არ იყო მხოლოდ „ქარიშხალი ჩაის ფინჯანში“, არამედ სიტუაციიდან გამოსვლის რეალური გამოსავალი, მე ავიღე მაქსიმალური პასუხისმგებლობა, მოვაშორე გუნდიდან უსიამოვნო რუტინა.

წელიწადნახევარი გავიდა უკვე და პროექტი ზეგანაკვეთური სამუშაოების გარეშე, „ვირთხების რბოლების“ და ყველანაირი სტრესის გარეშე ვითარდება. ძველ გუნდში ზოგს არ სურდა ასე მუშაობა და წავიდა, ზოგს კი პირიქით ძალიან გაუხარდა გამჭვირვალე წესების გამოჩენა. მაგრამ საბოლოო ჯამში, გუნდში ყველა ძალიან მოტივირებულია და სრულად იცნობს უზარმაზარ პროექტს, მათ შორის როგორც წინა, ისე უკანა ნაწილი. მათ შორის როგორც კოდის ბაზა, ასევე მთელი ბიზნეს ლოგიკა. საქმე იქამდეც კი მივიდა, რომ ჩვენ არ ვართ უბრალოდ „ნიჩბები“, არამედ ჩვენ თვითონ ვხვდებით ბევრ ბიზნეს პროცესს და ახალ მახასიათებელს, რომელიც ბიზნესს მოსწონს.

ჩვენი მხრიდან ამ მიდგომის წყალობით, მომხმარებელმა გადაწყვიტა შეუკვეთა ჩვენი კომპანიის სხვა ბაზარი, რაც კარგი ამბავია.

რადგან ეს მუშაობს ჩემს პროექტზე, იქნებ ის ასევე დაეხმარება ვინმეს. ასე რომ, თავად პროცესი, რომელიც დაგვეხმარა პროექტის გადარჩენაში:

გუნდური მუშაობის პროცესი პროექტზე "ჩემი საყვარელი პროექტი"

ა) შიდა გუნდის პროცესი (დეველოპერებს შორის)

• ყველა საკითხი იქმნება ჯირას სისტემაში
• თითოეული დავალება უნდა იყოს აღწერილი მაქსიმალურად და შეასრულოს მკაცრად ერთი მოქმედება
• ნებისმიერი მახასიათებელი, თუ ის საკმარისად რთულია, იყოფა ბევრ პატარა ამოცანად
• გუნდი მუშაობს ფუნქციებზე, როგორც ერთი ამოცანა. პირველ რიგში, ჩვენ ყველა ერთად ვმუშაობთ ერთ ფუნქციაზე, ვაგზავნით მას ტესტირებისთვის და შემდეგ ვიღებთ შემდეგს.
• თითოეული დავალება მონიშნულია, მისი უკანა ნაწილისთვის ან წინა ნაწილისთვის
• არსებობს დავალებების და შეცდომების ტიპები. თქვენ უნდა მიუთითოთ ისინი სწორად.
• დავალების შესრულების შემდეგ ის გადადის კოდის განხილვის სტატუსში (ამ შემთხვევაში იქმნება კოლეგის მოთხოვნის მოთხოვნა)
• ადამიანი, რომელმაც დაასრულა დავალება, მაშინვე აკონტროლებს თავის დროს ამ ამოცანის შესრულებას.
• კოდის შემოწმების შემდეგ, PR დაამტკიცებს და ამის შემდეგ, ვინც ეს დავალება დამოუკიდებლად შეასრულა, აერთიანებს მას მთავარ ფილიალში, რის შემდეგაც ცვლის მის სტატუსს დეველ სერვერზე განლაგებისთვის მზადყოფნაში.
• დეველ სერვერზე განლაგებისთვის მზად ყველა დავალება განლაგებულია გუნდის ხელმძღვანელის მიერ (მისი პასუხისმგებლობის სფერო), ზოგჯერ გუნდის წევრის მიერ, თუ რამე გადაუდებელია. განლაგების შემდეგ, ყველა დავალება განლაგებისთვის მზადიდან dev-მდე გადადის სტატუსზე - მზად არის ტესტირებისთვის dev-ზე
• ყველა დავალება შემოწმებულია მომხმარებლის მიერ
• როდესაც მომხმარებელი გამოსცადა დავალება დეველოპერზე, ის გადასცემს მას სტატუსს, რომელიც მზად არის განლაგებისთვის წარმოებაში
• წარმოებაში განლაგებისთვის, ჩვენ გვაქვს ცალკე ფილიალი, სადაც მასტერს ვაერთებთ მხოლოდ განლაგებამდე
• თუ ტესტირების დროს მომხმარებელი აღმოაჩენს შეცდომებს, ის აბრუნებს დავალებას გადასინჯვისთვის, ადგენს მის სტატუსს, როგორც დაბრუნებული გადასინჯვისთვის. ამ გზით ჩვენ გამოვყოფთ ახალ დავალებებს მათგან, რომლებმაც ვერ გაიარეს ტესტირება.
• შედეგად, ყველა დავალება მიდის შექმნიდან დასრულებამდე: გასაკეთებელი → განვითარებაში → კოდის მიმოხილვა → მზადაა განლაგდეს დეველოპმენტზე → QA დეველოპმენტზე → (დაბრუნება განვითარებულზე) → მზადაა განლაგდეს პროდ → QA პროდზე → შესრულებულია
• თითოეული დეველოპერი ამოწმებს თავის კოდს დამოუკიდებლად, მათ შორის, როგორც საიტის მომხმარებელი. დაუშვებელია ფილიალის გაერთიანება მთავარში, თუ დანამდვილებით არ არის ცნობილი, რომ კოდი მუშაობს.
• ყველა ამოცანას აქვს პრიორიტეტები. პრიორიტეტებს ადგენს კლიენტი ან გუნდის ლიდერი.
• დეველოპერები პირველ რიგში ასრულებენ პრიორიტეტულ დავალებებს.
• დეველოპერებს შეუძლიათ დაავალონ ერთმანეთს დავალებები, თუ სისტემაში აღმოჩენილია სხვადასხვა შეცდომები ან ერთი ამოცანა შედგება რამდენიმე სპეციალისტის მუშაობისგან.
• ყველა დავალება, რომელსაც მომხმარებელი ქმნის, გადადის გუნდის ლიდერზე, რომელიც აფასებს მათ და ან სთხოვს მომხმარებელს მათ შეცვლას ან ანიჭებს მათ გუნდის ერთ-ერთ წევრს.
• ყველა ამოცანა, რომელიც მზად არის განსათავსებლად, ასევე გადადის გუნდის ლიდერზე, რომელიც დამოუკიდებლად განსაზღვრავს როდის და როგორ განახორციელოს განლაგება. ყოველი განლაგების შემდეგ, გუნდის ლიდერმა (ან გუნდის წევრმა) უნდა აცნობოს მომხმარებელს ამის შესახებ. ასევე შეცვალეთ ამოცანების სტატუსები, რათა მზად იყოს ტესტირებისთვის dev/cont-ისთვის.
• ყოველდღე ერთსა და იმავე დროს (ჩვენთვის 12.00 საათზე) ვმართავთ შეხვედრას გუნდის ყველა წევრს შორის
• შეხვედრაზე ყველა ანგარიშს უწევს, მათ შორის გუნდის ლიდერი, რა გააკეთეს გუშინ და რას გეგმავენ დღეს. რა არ მუშაობს და რატომ. ამ გზით მთელმა გუნდმა იცის ვინ რას აკეთებს და რა ეტაპზეა პროექტი. ეს გვაძლევს შესაძლებლობას ვიწინასწარმეტყველოთ და მოვარგოთ, საჭიროების შემთხვევაში, ჩვენი შეფასებები და ვადები.
• შეხვედრაზე გუნდის ხელმძღვანელი ასევე საუბრობს პროექტში განხორციელებულ ყველა ცვლილებაზე და მიმდინარე ხარვეზების დონეზე, რომლებიც მომხმარებელმა ვერ აღმოაჩინა. ყველა ხარვეზი დალაგებულია და ენიჭება გუნდის თითოეულ წევრს მათ მოსაგვარებლად.
• შეხვედრაზე გუნდის ლიდერი ანიჭებს დავალებებს თითოეულ ადამიანს, დეველოპერების მიმდინარე დატვირთვის, მათი პროფესიული მომზადების დონის გათვალისწინებით და ასევე კონკრეტული დავალების სიახლოვის გათვალისწინებით, რასაც დეველოპერი ამჟამად აკეთებს.
• შეხვედრაზე გუნდის ლიდერი შეიმუშავებს არქიტექტურისა და ბიზნეს ლოგიკის ზოგად სტრატეგიას. რის შემდეგაც მთელი გუნდი განიხილავს ამ საკითხს და გადაწყვეტს შეცვალოს ან მიიღოს ეს სტრატეგია.
• თითოეული დეველოპერი წერს კოდს და აშენებს ალგორითმებს დამოუკიდებლად ერთი არქიტექტურისა და ბიზნეს ლოგიკის ფარგლებში. ყველას შეუძლია გამოხატოს თავისი ხედვა განხორციელების შესახებ, მაგრამ არავინ აიძულებს ვინმეს ამის გაკეთებას ასე და არა სხვაგვარად. ყოველი გადაწყვეტილება გამართლებულია. თუ არის უკეთესი გამოსავალი, მაგრამ ახლა ამის დრო არ არის, მაშინ ცხიმში იქმნება დავალება კოდის გარკვეული ნაწილის მომავალი რეფაქტორაციისთვის.
• როდესაც დეველოპერი იღებს დავალებას, ის გადასცემს მას განვითარების სტატუსს. კლიენტთან დავალების გარკვევასთან დაკავშირებული ყველა კომუნიკაცია დეველოპერის მხრებზე მოდის. ტექნიკური კითხვები შეიძლება დაუსვან გუნდის ლიდერს ან კოლეგებს.
• თუ დეველოპერს არ ესმის დავალების არსი და მომხმარებელმა ვერ შეძლო მისი გარკვევით ახსნა, მაშინ ის გადადის შემდეგ დავალებაზე. და გუნდის ლიდერი იღებს მიმდინარე და განიხილავს მას მომხმარებელთან.
• ყოველდღე, დეველოპერმა უნდა დაწეროს კლიენტის ჩატში, თუ რა ამოცანებზე მუშაობდა გუშინ და რა ამოცანებზე იმუშავებს დღეს
• სამუშაო პროცესი მიმდინარეობს Scrum-ის მიხედვით. ყველაფერი დაყოფილია სპრინტებად. თითოეული სპრინტი ორი კვირა გრძელდება.
• სპრინტები იქმნება, ივსება და იხურება გუნდის ლიდერის მიერ.
• თუ პროექტს აქვს მკაცრი ვადები, მაშინ ვცდილობთ დაახლოებით შევაფასოთ ყველა დავალება. და ჩვენ მათ ერთად ვაყენებთ სპრინტში. თუ მომხმარებელი შეეცდება მეტი დავალების დამატებას სპრინტში, მაშინ ჩვენ ვადგენთ პრიორიტეტებს და გადავიტანთ სხვა დავალებებს შემდეგ სპრინტზე.

ბ) მომხმარებელთან მუშაობის პროცესი

• თითოეულ დეველოპერს შეუძლია და უნდა დაუკავშირდეს მომხმარებელს
• მომხმარებელს არ უნდა მიეცეს უფლება დააწესოს საკუთარი თამაშის წესები. აუცილებელია ზრდილობიანად და მეგობრულად ავუხსნათ მომხმარებელს, რომ ჩვენ ვართ ჩვენი დარგის სპეციალისტები და მხოლოდ ჩვენ უნდა ავაშენოთ სამუშაო პროცესები და ჩავრთოთ მომხმარებელი მათში.
• იდეალურ შემთხვევაში, ნებისმიერი ფუნქციონირების დანერგვის დაწყებამდე აუცილებელია მახასიათებლისთვის (სამუშაო ნაკადის) მთელი ლოგიკური პროცესის დიაგრამის შექმნა. და გაუგზავნეთ მომხმარებელს დასადასტურებლად. ეს ეხება მხოლოდ რთულ და არა აშკარა ფუნქციონირებას, მაგალითად, გადახდის სისტემას, შეტყობინებების სისტემას და ა.შ. ეს საშუალებას მოგვცემს უფრო ზუსტად გავიგოთ რა სჭირდება მომხმარებელს, შეინახოს დოკუმენტაცია მახასიათებლისთვის და ასევე დავაზღვიოთ თავი იმისგან, რომ მომხმარებელმა შეიძლება თქვას, რომ ჩვენ არ გავაკეთეთ ის, რაც მან მოითხოვა.
• ყველა დიაგრამა/დიაგრამა/ლოგიკა და ა.შ. ჩვენ ვინახავთ Confluence/Fat-ში, სადაც მომხმარებელს ვთხოვთ კომენტარებში დაადასტუროს მომავალი განხორციელების სისწორე.
• ვცდილობთ არ დავამძიმოთ მომხმარებელი ტექნიკური დეტალებით. თუ ჩვენ გვჭირდება იმის გაგება, თუ როგორ სურს მომხმარებელს ეს, მაშინ ვხატავთ პრიმიტიულ ალგორითმებს flowchart-ის სახით, რომელიც მომხმარებელს შეუძლია თავად გაიგოს და შეასწოროს/შეცვალოს ყველაფერი.
• თუ მომხმარებელი აღმოაჩენს შეცდომას პროექტში, მაშინ გთხოვთ, დეტალურად აღწეროთ იგი Zhira-ში. რა ვითარებაში მოხდა, როდის, მოქმედებების რა თანმიმდევრობა განხორციელდა მომხმარებლის მიერ ტესტირებისას. გთხოვთ დაურთოთ ეკრანის ანაბეჭდები.
• ჩვენ ვცდილობთ ყოველდღე, მაქსიმუმ ყოველ მეორე დღეს, განვათავსოთ დეველ სერვერზე. ამის შემდეგ მომხმარებელი იწყებს ფუნქციონირების შემოწმებას და პროექტი არ დგას უმოქმედოდ. ამავდროულად, მომხმარებლისთვის ეს არის ნიშანი იმისა, რომ პროექტი სრულ განვითარებაშია და მას არავინ უყვება ზღაპრებს.
• ხშირად ხდება, რომ მომხმარებელს ბოლომდე არ ესმის რა სჭირდება. იმიტომ, რომ ის თავისთვის ქმნის ახალ ბიზნესს, ჯერ ჩამოყალიბებული პროცესებით. აქედან გამომდინარე, ძალიან გავრცელებული სიტუაციაა, როდესაც ჩვენ ვყრით კოდის მთელ ნაწილს ნაგავში და აპლიკაციის ლოგიკას ხელახლა ვქმნით. აქედან გამომდინარეობს, რომ აბსოლუტურად ყველაფერი ტესტებით არ უნდა დაფაროთ. აზრი აქვს მხოლოდ კრიტიკული ფუნქციების დაფარვას ტესტებით, შემდეგ კი მხოლოდ დაჯავშნით.
• არის სიტუაციები, როდესაც გუნდი ხვდება, რომ ჩვენ არ ვასრულებთ ვადებს. შემდეგ ვაწარმოებთ ამოცანების სწრაფ აუდიტს და ამის შესახებ დაუყოვნებლივ ვაცნობთ მომხმარებელს. სიტუაციიდან გამოსავალად, ჩვენ ვთავაზობთ მნიშვნელოვანი და კრიტიკული ფუნქციების დროულად დაწყებას, ხოლო დანარჩენის დატოვება გამოშვების შემდგომ.
• თუ მომხმარებელი იწყებს სხვადასხვა ამოცანების გამოგონებას, იწყებს ფანტაზიას და თითებით ახსნას, მაშინ ვთხოვთ, მოგვაწოდოს გვერდის განლაგება და ლოგიკა, რომელიც სრულად უნდა აღწერდეს მთელი განლაგების ქცევას და მისი ელემენტები.
• რაიმე დავალების შესრულებამდე უნდა დავრწმუნდეთ, რომ ეს ფუნქცია შედიოდა ჩვენი შეთანხმების/კონტრაქტის პირობებში. თუ ეს არის ახალი ფუნქცია, რომელიც სცილდება ჩვენს თავდაპირველ შეთანხმებებს, მაშინ ჩვენ უნდა დავაფასოთ ეს ფუნქცია ((დასრულების სავარაუდო დრო + 30%) x 2) და მივუთითოთ მომხმარებელს, რომ ამდენი დრო დაგვჭირდება მის დასრულებას, პლუს ვადა გადაინაცვლებს შეფასების დროზე გამრავლებული ორზე. მოდით დავალება უფრო სწრაფად შევასრულოთ - მშვენიერია, ამით ყველა ისარგებლებს. თუ არა, მაშინ ჩვენ დაგიფარავთ.

გ) რასაც არ ვიღებთ გუნდში:

• დაუმორჩილებლობა, სიმშვიდის ნაკლებობა, დავიწყება
• "საუზმის კვება." თუ თქვენ ვერ შეასრულებთ დავალებას და არ იცით როგორ, მაშინ დაუყოვნებლივ უნდა აცნობოთ ამის შესახებ გუნდის ლიდერს და არ დაელოდოთ ბოლო წუთს.
• წარბები და ტრაბახობს ადამიანი, რომელსაც ჯერ არ დაუმტკიცებია თავისი შესაძლებლობები და პროფესიონალიზმი. თუ დადასტურდა, მაშინ შესაძლებელია, წესიერების ფარგლებში :)
• მოტყუება ყველა მისი ფორმით. თუ დავალება არ არის დასრულებული, მაშინ არ უნდა შეცვალოთ მისი სტატუსი დასრულებულად და ჩაწეროთ კლიენტის ჩატში, რომ ის მზად არის. კომპიუტერი გაფუჭდა, სისტემა გაფუჭდა, ძაღლმა ლეპტოპი დაღეჭა - ეს ყველაფერი მიუღებელია. თუ რეალური ფორსმაჟორული მოვლენა მოხდა, გუნდის ლიდერს დაუყოვნებლივ უნდა ეცნობოს.
• როცა სპეციალისტი მუდმივად ოფლაინშია და სამუშაო საათებში მასთან დაკავშირება რთულია.
• გუნდში ტოქსიკურობა დაუშვებელია! თუ ვინმე რამეს არ ეთანხმება, მაშინ ყველა იკრიბება მიტინგზე და განიხილავს და წყვეტს.

და რიგი კითხვები/თეზისები, რომლებსაც ზოგჯერ ვეკითხები ჩემს მომხმარებელს ყველა გაუგებრობის გასარკვევად:

1. რა არის თქვენი ხარისხის კრიტერიუმები?
2. როგორ განვსაზღვროთ, აქვს თუ არა პროექტს პრობლემები?
3. სისტემის შეცვლის/გაუმჯობესების შესახებ ჩვენი ყველა რეკომენდაციისა და რჩევის დარღვევით, ყველა რისკი მხოლოდ თქვენ გეკისრებათ
4. პროექტში რაიმე მნიშვნელოვანი ცვლილება (მაგალითად, ყველა სახის დამატებითი ნაკადი) გამოიწვევს შეცდომების შესაძლო გამოჩენას (რასაც ჩვენ, რა თქმა უნდა, გამოვასწორებთ)
5. შეუძლებელია რამდენიმე წუთში იმის გაგება, თუ რა სახის პრობლემა შეექმნა პროექტს, მით უმეტეს, რომ დაუყოვნებლივ გამოსწორდეს
6. ჩვენ ვმუშაობთ პროდუქტის კონკრეტულ ნაკადზე (დავალებები ჟირაში - განვითარება - ტესტირება - განლაგება). ეს ნიშნავს, რომ ჩვენ ვერ ვუპასუხებთ ჩეთში მოთხოვნისა და საჩივრების მთელ ნაკადს.
7. პროგრამისტები არიან პროგრამისტები და არა პროფესიონალი ტესტერები და ვერ უზრუნველყოფენ პროექტის ტესტირების სათანადო ხარისხს
8. პასუხისმგებლობა საბოლოო ტესტირებაზე და წარმოების ამოცანების მიღებაზე მთლიანად თქვენ გეკისრებათ
9. თუ ჩვენ უკვე ავიღეთ დავალება, ჩვენ არ შეგვიძლია დაუყოვნებლივ გადავიდეთ სხვაზე, სანამ არ დავასრულებთ მიმდინარე ამოცანას (თორემ ეს გამოიწვევს კიდევ უფრო მეტ შეცდომებს და გაზრდის განვითარების დროს)
10. გუნდში ნაკლები ხალხია (დასვენების ან ავადმყოფობის გამო), მაგრამ მეტი სამუშაოა და ფიზიკურად არ გვექნება დრო, რომ ვუპასუხოთ ყველაფერს, რაც გინდა.
11. ჩვენ გთხოვთ, განახორციელოთ წარმოებაზე განლაგება დეველოპერზე გამოცდილი ამოცანების გარეშე - ეს მხოლოდ თქვენი რისკია და არა დეველოპერები
12. როდესაც თქვენ აყენებთ გაურკვეველ ამოცანებს, სწორი ნაკადის გარეშე, დიზაინის განლაგების გარეშე, ეს მოითხოვს ჩვენგან ბევრად მეტ ძალისხმევას და განხორციელების დროს, რადგან ჩვენ უნდა გავაკეთოთ დამატებითი სამუშაო თქვენს ნაცვლად.
13. შეცდომების შესახებ ნებისმიერი დავალება, მათი წარმოშობის დეტალური აღწერისა და ეკრანის ანაბეჭდების გარეშე, არ გვაძლევს შესაძლებლობას გავიგოთ, რა მოხდა არასწორად და როგორ შეგვიძლია გამოვასწოროთ ეს შეცდომა
14. პროექტი მოითხოვს მუდმივ დახვეწას და გაუმჯობესებას შესრულებისა და უსაფრთხოების გასაუმჯობესებლად. ამიტომ, გუნდი დროის ნაწილს ხარჯავს ამ გაუმჯობესებაზე
15. იმის გამო, რომ საათობრივად გვაქვს ზეგანაკვეთური სამუშაოები (სასწრაფო შესწორებები), სხვა დღეებში უნდა ავინაზღაუროთ.

როგორც წესი, მომხმარებელს მაშინვე ესმის, რომ პროგრამული უზრუნველყოფის შემუშავებაში ყველაფერი არც ისე მარტივია და მხოლოდ სურვილი აშკარად არ არის საკმარისი.

ზოგადად, ეს ყველაფერია. კულისებში ვტოვებ უამრავ მოლაპარაკებას და ყველა პროცესის თავდაპირველ გამართვას, მაგრამ შედეგად, ყველაფერი გამოვიდა. შემიძლია ვთქვა, რომ ეს პროცესი ჩვენთვის ერთგვარი „ვერცხლის ტყვია“ გახდა. პროექტში მოსულ ახალ ადამიანებს პირველივე დღიდან შეეძლოთ დაუყოვნებლივ ჩაერთონ სამუშაოში, რადგან აღწერილი იყო ყველა პროცესი, ხოლო დოკუმენტაცია და არქიტექტურა დიაგრამების სახით მაშინვე წარმოდგენას აძლევდა, თუ რას ვაკეთებდით აქ ყველა.

PS მინდა განვმარტო, რომ ჩვენს მხარეს არ არის პროექტის მენეჯერი. ეს არის მომხმარებლის მხარეზე. საერთოდ არ არის ტექნიკური. ევროპული პროექტი. ყველა კომუნიკაცია მხოლოდ ინგლისურ ენაზეა.

წარმატებებს გისურვებთ ყველას თქვენს პროექტებში. არ დაიწვათ და შეეცადეთ გააუმჯობესოთ თქვენი პროცესები.

წყარო ჩემშია ბლოგის პოსტი.

წყარო: www.habr.com