ზრდის ფაზა - 23 - პროგრამული და ინფრასტრუქტურული გამოწვევები

ხშირად ხდება ხოლმე რომ სტარტაპებს იწყებენ ისე რომ რთულია შემდეგ დიდი რაოდენობის მოხმმარებლების გაძლება.

ანუ სტარტაპის განვითარებისას დიდი მნიშვნელობა აქვს რამდენა უზრუნველყოფილია SCALABILITY- ანუ მასშტაბირება.  ეს ასევე კარგი გამოცდაა CTO-სი.

ამსათვის როგორც მანამდე გვქონდა საუბარი, კარგი გამოსავალია STRESS TEST-ები.
ასევე CTO-ს უნდა დაავალოთ რომ გაწიოს მონიტორინგი სერვერების გამართულ მუშაობაზე, სერვისების გამართულ მუშაობაზე, ბაზების  და ა.შ.

ეს თქვენ საშუალებას მოგცემთ გამოავლინოთ ინფრასტრუქტურის bottleneck-ი, რომლებიც როგორც წესი, ხშირ შემთხვევაში ერთი და იგივეა. 

სერვერის შესაძლებლობების გაზრდა ყოველთვის არ არის საკმარისი. 

საბედნიეროდ ამისათვის არსებობს კარგი გამოსავალი.

აქ არის პირველი კლასიკური bottleneck-ი. SERVER BANDWIDTH – THE UPLOAD BANDWIDTH. 

ამის გამოსწორება მარტივია CDN-ის საშუალებით.

Cache optimization

ტექნილოგიები როგორიცაა memcash ან  vanish , დაგიზოგავთ ტონობით ფულს  ინფრასტრუქტურაში, თუ თქვენ იყენებთ ქეშს. (cache).

SQL კარგია რეპორტების კეთებისთვის, მაგრამ უფრო ნელია მუშაობაში. 

NOSQL database არის რთული სტრუქტურის და მეტად კომპლექსურია დეველოპმენტისთვის. 

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

ცალკე მდგომი სერვერი არ არის ზრდისთვის ადაპტირებული. 

უცებ აგიხსნით ზრდისთვის განკუთვნილ გადაწყვეტილებებს.

• Server - კომპიუტერი რომელიც დაჰოსტილია მონაცემთა ცენტრში (data center)
• Virtual server - ეს არის ვირტუალური გარემო, რომელიც მუშაობს ფიზიკურ სერვერებზე. 
• Cloud services - ეს მომწოდებლები უზრუნველყოფენ როგორც VIRTUAL SERVER-ებს, ასევე APPLICATION BASED SERVICE-ბსაც. 

სწრაფი ზრდისთვის მე გირჩევთ რომ გამოიყენოთ CLOUD SERVICE-ბი, ეს არის ვირტუალური გარემო მონაცემებისთვის, რომელიც არ საჭიროებს დამატებით მოვლას სერვერული ინფრასტრუქტურისთვის. 

თუ თქვენ გაქვთ ერთ დღეს 10 მომხმარებელი და მეორე დღეს 10 000 მომხმარებელი, სერვერი თავისით გაიზდება თქვენი ჩარევის გარეშე. 

ჩვენ გვაქვს იგივე პრინციპი მონაცემთა ბაზებისთვის

ამას ჰქვია DATABASE AS A SERVICE

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

ზრდის ფაზა - 22 მზარდი გუნდის გამოწვევები და ორგანიზაცია

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

ეს არის PRODUCT OWNER_ის პასუხისმგებლობის ნაწილი.
რომ გავიხსენოთ რა არის მისი მოვალეობები: ეს არის რომ მიიღოს გადაწყვეტილებები რა feature- ები გაკეთდეს და რა გადაიდოს.

ეს არის ერთგვარი კლიენტი ტექნიკური გუნდისთვის.

მაშინ როცა CTO უზრუნველყოფს საჭირო რესურსების მობილიზებას, PRODUCT OWNER_ი წყვეტს რა ფუნქციონალი შეიქმნას ამ რესურსების გამოყენებით.
PRODUCT OWNER-ის როლი არის საკვანძო როლი ზრდის ეტაპზე.

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

დამფუძნებლისთვის ეს რთული დროა, ეს იმას ჰგავთ თითქოს product owner_მა მოიპარა მისი პირმშო.  მაგრამ არ შეგეშინდეთ, დამფუძლებელს ყოველთვის შეუძლია გაუზიაროს მისი აზრი პროდუქტის განვითარებასთან დაკავშირებით და  კარგმა product owner-მა უნდა მოუსმინოს ამ აზრებს.

როდესაც ვსაუბრობთ product owner-ზე, უნდა დარწმუნდეთ რომ ის სრულიად განსხვავებული იქნება CTO-სგან.

მაგალითად product owner-ი უნდა იყოს მარკეტოლოგი და ესმოდეს ტექნიკური საკითხები კარგად, ხოლო CTO უნდა იყოს ტექნიკურ საკითხებში ძალიან ძლიერი და ჰქონდეს კარგი გაგება მარკეტინგისა მარკეტინგზე.

ძალიან მნიშვნელოვანია რომ ამ ორ პიროვნებას ესმოდეს ერთმანეთის და ამიტომაც არის საჭირო რომ გარკვეულიგ გაგება ჰქონდეთ ერთმანეთის ძირითადის საქმიანობებისю 

მაშინ როცა product owner_ი მოიფიქრებს გარკვეულ ფუნქციონალს და გაანდობს CTO-ს, CTO-მ ამასთან დაკავშირებით უნდა მოიფიქროს და შესთავაზოს product owner-ს ტექნიკური გადაწყვეტები ამ ახალ ფუნქციონალთან დაკავშირებით, ეს ასევე გულისხმობს ამ ფუნქციონალის ინოვაციურ ჭრილში გადაწყვეტასაც(უფრო სწორედ ასე უდნა მოხდეს IMHO). 

პროექტის მენეჯმენტის ნაწილში, გასათვალისწინებელია ერთი ძალზედ მნიშვნელოვანი საკითხი

REPORTING

რეპორტინგი აუცილებელია ყველანაირი ტიპის DELEGATION-ისთვის, იქნება ეს outsourcing_ი თუ შიდა გუნდი. 

ეს საკითხი რომ გავითვალისწინოთ არის 5 კითხვა შემსრულებლებთან, არ აქვს მნიშვნელობა ეს იქნება ვებ სააგენტო, FREELANCER_ი თუ შდა გუნდი

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

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

ასევე არის ძალიან მნიშვნელოვანი საკითხი. კერძოდ როცა თქვენ გყავთ მზარდი გუნდი, თქვენ უნდა გქონდეთ SMOOTH ORGANIZATION (კარგად ორგანიზებული უნდა იყოთ გუნდის მართვის ნაწილში), ეს ნიშნავს რომ უნდა გქონდეთ HIGH AGILE ORGANIZATION. 

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

შემდეგი ასპექტი არის smooth organization_ის ქონა, მაღალი AGILITY-ს გათვალისწინებით. 

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

ეს შესაძლებელია იმ შემთხვევაში თუ სრულდება შემდეგი ორი პირობა. 

მაგრამ რა არის ეს?

გახსოვთ სხვადასხვა გარემოები?

• DEVELOPMENT ENVIRONMENT
• TEST ENVIRONMENT
• PRODUCTION ENVIRONMENT?

Continuous integration არის ავტომატური პროცესი, რომელიც გაძლევთ საშუალებას პატარა კოდის საფუძველზე,  მოახდინოთ deploy თითოეულ environment-ში, უბრალოდ განსაზღვრულ ღილაკზე დაჭერით. 

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

ეს უზრუნველყოფს პროგრამის სწრაფ განახლებას. 

შემდეგი კონცეპტი არის continuous deployment, ეს არის ზუსტად იგივე პრინციპი რაც Continuous integration, მაგრამ ღილაკის გარეშე. 

ღილაკი მაგივრად არის პატარა სკრიპტი. 

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

გულახდილად რომ ვთქვათ, ამ ხარისხის და დონის  მიღწევა რთული საქმეა,ეს მოითხოვს ბევრ დროს და მაღალ ხარისხს. 

მაგრამ როცა ამას მიაღწევთ, თქვენ გექნებათ შესაძლებლობა გაზარდოთ თქვენი გუნდი და ამავდროულად დარჩეთ AGILE-ად. 

როცა მზარდ გუნდზე ვსაუბრობთ, რა მოხდება მაშინ თუ ორმა დეველოპერმა შეცვალა ერთიდაიგივე SOURCE CODE-ის ფაილი?

SOURCE CODE REPOSITORY SOLUTIONS- მაგალითდ GIT_ი მართავს ამ პროცესს. 

ამისათვის არის კარგი პრაქტიკა:

რაც ნიშნავს რომ ყოველ დეველოპერს შეუძლია ჰქონდეს source code_ის საკუთარი კოპია. 

როცა დეველოპერი დაამთავრებს მის სამუშაოს, ანუ ერთ feature-ს.  ის გაა_publish-ებს ეგრეთ წოდებულ pool request. შემდგომ product owner ან scrum master-ი შეამოწმებს commit-ებს და დარწმუნდება რომ ყველაფერი წესრიგშია  და მხოლოდ ამის შემდეგ გაუკეთებს MERGE-ს, ამ დეველოპერის SOURCE CODE-ს, მთავარ repository-ში. 

ამ პრინციპს ჰქვია GITFLOW. და ამისთვის არსებობს TOOL_ები, რომ ასეთი გზით მოხდეს source code_ის მენეჯმენტი 

რომ შევაჯამოთ ეს ნაწილი

ეს რამოდენიმე პრინციპი მოითხოვს კვირეების და თქვეების მუშაობას. 

მაგრამ ეს მოგცემთ საშუალებას რომ გახდეთ უფრო და უფრო დიდი  და სწრაფად მოახდინოთ რეაგირება მომხმარებლების მოთხოვნებზე და შესაბამისად დარჩეთ AGILE.

ზრდის ფაზა - 21 შიდა გუნდის ფორმირება

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

შიდა გუნდის ქონა ნიშნავს:

პირველ რიგში ბიზნესისთვის საჭირო და მიზანშეწონილია რომ იქირავოთ FULL STACK DEVELOPER -ი. ან LEAD DEVELOPER_ი. 

ეს არის ადამიანი რომელსაც  წესით შეეძლება მომავალში რომ რამოდენიმე დეველოპერი მართოს. 

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

და ასევე შეიძლება მიიღოს გადაწყვეტილებები რომ დატოვოს ჯერ OUTSOURCE კომპანია სამუშაოდ, სანამ მოხდება TRANSITION_ის პროცესი. 

თუ თქვენ კომპანიას სწრაფი ზრდა ექნება, ეს მოითხოვს CTO-ს ყოლას.  ვინაიდან ზრდის ფაზა მოითხოვს მეტ ტექნიკურ და მენეჯმენტის SKILL-ებს, რომ გაუმკლავდეთ ზრდის ფაზას. 

ამ მომენტში მე ძალიან მომწონს ხოლმე ის მიდგომა, როცა LEAD დეველოპერს ამზადებენ და ასწავლიან შესაბამისად CTO-დ გახდომისთვის. 

სამწუხაროდ ყველა მათგანი არ არის მზად რომ გახდეს კარგი მენეჯერი. მაგრამ ცდად ღირს. 

მოდი ახლა აღვწეროთ CTO-ს როლი. 

ეს არის კომპანიისთვის სტრატეგიული როლი. 

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

გარდა ამისა, მან ასევე უნდა უხელმძღვანელოს ოპერაციულ ნაწილსაც რომ გაუმკლავდეს ბიზნესის ზრდის გამოწვევას. 

რა პასუხისმგებლობები აქვს CTO-ს?

როცა ვსაუბრობთ OUTSOURCE RESOURCE_ბზე, ჩვენ ვქულისხმობთ

ასევე,  CTO არის პასუხისმგებელი რომ უზრუნველყოს სერვისის გამართლი მუშაობა. 

მაგრამ როგორ უნდა გაუმკლავდეს ამ პასუხისმგებლობას?

რა წერია disaster recovery plan-ში

ეს პროცედურები არის დროდადრო გასაახლებელი და ეს არის CTO_ს პასუხისმგებლობა. 

და ბოლოს, CTO-მ ასევე პასუხისმგებლობა უნდა აიღოს ბიუჯეტზე.

რომ გავამარტივოთ CTO-სთვის მოსათხოვი SKILL_ები არის შემდეგი: 

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

ასე რომ შევაჯამოთ ეს ნაწილი. 

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

და ამისათვის მინიმუმ უნდა გყავდეს მინიმუმ ეს ორი კადრი.: 

პროდუქტის განვითარების ფაზა - 20 უსაფრთხოება

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

ამის უზრუნველსაყოფად არის რამოდენიმე კითხვა, რაც უნდა დაუსვათ თქვენ ტექნიკურ გუნდს.
პირველ რიგში software-ის ნაწილში, უნდა სთხოვოთ რომ გააკეთონ CODE REVIEW.  ან შეიძლება კარგი აზრი იყოს რომ დაიქირავოთ სხვა დეველოპერები რომ გადახედონ კოდს მათ მაგივრად. (ეს უფრო აზრიანი ვარიანტი მგონია, დაზღვევის ამბავში).

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

ასევე გირჩევთ რომ დანერგოთ :

• ცენტრალიზებული LOG-ების სისტემა და
• ALERT-ების სისტემა

რაც დაგეხმარებათ უსაფრთხოების ნაწილში და ასევე შეცდომების აღმოფხვრის ნაწილშიც.
სხვა გადაწყვეტილებები?

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

ამ საკვანძო რეგულაციებისთვის არის საკვანძო ROLE-ბი. 

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

DATA PROCESSOR

: ნებისმიერი ტიპის სუბკონტრაქტორი, რომელსაც აქვს მონაცემებთან წვდომა. 

Data protection Officer

DATA PROTECTION AUTHORITY

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

ზოგ შემთხვევებში შეიძლება აუცილებელი იყოს რომ მონაცემები ანონიმურად იქნას შენახული, მაგალითად BIG DATA-ს ან machine learning მიზნებისთვის. 

პროდუქტის განვითარების ფაზა - 19 ხარისხის მენეჯმენტი

როცა კონტრაქტს აფორმებთ ვენდორთან, უნდა დარწმუნდეთ იმაში რომ quality assurance-ს უზრუნველყოფენ თავად, ანუ მოგიწევთ თუ არა თქვენ ყველაფრის თავად შემოწმება, თუ ისინი ამას თავად განახორციელებენ?
ასე რომ თუ პროვაიდერი არის იაფი, ან თქვენ ურთიერთობთ freelancer-თან, ეს ნიშნავს რომ quality assurance_ის კეთება თავად მოგიწევთ.
მოკლედ, რის გათვალისწინება მოგიწევთ
პირველი რაშიც უნდა დარწმუნდეთ არის ის, რომ გქონდეთ რამოდენიმე გარემო:

• დეველოპმენტის გარემო
• სატესტო გარემო
• ფროდაქშენის გარემო

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

იყენებენ თუ არა ისინი, ავტომატურ ტესტირებას დეველოპმენტის ნაწილში?

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

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

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

კარგი გამოსავალია რომ არსებობდეს ტესტირების სცენარი მთლიანი აპლიკაციისთვის. 

ამისათვის გირჩევთ რომ გააკეთოთ თქვენი მომხმარებლის გზის აღწერა word_ის დოკუმენტში, შესაბამისი SCREENSHOT_ები და შესაბამისი FUNNEL-ებისთვის(ანუ ის გზები უნდა აღწეროთ რასაც რეალურად მომხმარებელი გაივლის დაგეგმილ მარშრუტზე  და სამიზნე გვერდამდე). 

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

ACCEPTANCE TEST - გირჩევთ რომ OFFSHORE-ზე გაიტანოთ ეს ტესტი. 

ბოლო რაც მინდა გითხრათ არის STRESS TEST_ი.

პროდუქტის განვითარების ფაზა - 18 პროგრამირების ენა და FRAMEWORK-ი

პროვაიდერთან ურიერთობისას, ძალიან მნიშვნელოვანია ენა რომელშიც დაიწერება თქვენი პროექტი, ეს მნიშვნელოვან წილად შეიძლება იყოს განპირობებული პროექტის მოთხოვნებიდან.
სანამ დავიწყებდეთ პროგრამირების ენებზე საუბარს, ჯერ გავიგოთ რა არის framework_ები.
Frameworks are a common methodology, usually based on open source. რაც იმას ნიშნავს რომ ამან შეიძლება დეველოპმენტის პროცესი დააჩქაროს და ასევე ის ხალხი ვინც ამ მეთოდოლოგიებს იყენებს გათვითცნობიერებულები არიან კარგი კოდის წერის პრინციპებში.

არ აქვს მნიშვნელობა ენას, თუ ისინი არ იყენებენ ამ მეთოდოლოგიას, გაიქეცით.. 

ეს ნიშნავს რომ ისინი ჩამორჩენილები არიან ახალი დეველოპმენტის მიდგომებისგან. 

ახლა რაც შეეხება DEVELOPMENT LANGUAGE-ბს. 

როგორც სასაუბრო ენები, ისეა ესეც, არ არსებობს საუკეთესო ან ერთი მეორეზე უკეთესი ენები, 

ყველა ენა შეიძლება იყოს რაღაცაში ცუდი და რაღაცაში კარგი.

გავიაროთ თითოეული

NODE JS

 ეს ენა ნელ-ნელა პოპულარობას იკრებს და უფრო მეტი დეველოპერი იქნება მომავალში. 

RUBY ON RAILS

Ruby on rails არის კარგი ვერსია, თუ თქვენ არ გჭრდებათ ძალიან დიდი გუნდი დიდი დროის მანძილზე.

PYTHON

ეს არის კარგი ვარიანტი იმ შემთხვევაში, თუ  large scale არ გექნებათ და მომავალში ARTIFICIAL INTELLIGENCE-ს გამოყენება დაგჭირდებად მომავალში.

JAVA

ეს უფრო ძველი სკოლაა და ამ ენაზე უფრო რთულია კეთება, არ გირჩევთ ამ ენაში კეთებას, თუ არ გყავთ დამფუძნებელი გუნდში, რომელმაც იცის ეს ენა.

ASP NET

როგორც დეველოპერებს ისე მეც დიდად არ მიყვარს Microsoft, მე მქონია გამოცდილება ურთიერთობის სტარტაპებთან რომელთაც შეექმნათ პრობლემები დეველოპერების პოვნაში, და ასევე სერვერული ინფრასტრუქტურის SCALABILITY_ში. 

ახლა განვიხილოთ MOBILE DEVELOPMENT –ის ნაწილი

აქ არის ოდი მიდგომა:

1. NATIVE LANGUAGE-ები - მაგ swift(ios), Java(android)

2. ჰიბრიდული ენები, რომლებსაც შეუძლიად გააკეთონ აპლიკაციები მობილურებისთვის.

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

Native language-ბი უფრო გამოიყენება

შემდეგისთვის: 

ეს უფრო სწრაფად მუშაბს და უფრო scalable არის პროექტებისთვის. 

პროდუქტის განვითარების ფაზა - 17 პროვაიდერის არჩევა დეველოპმენტისთვის

როგორ ავირჩიოთ development provider-ი?
• კომპანიის იმიჯი, სახელი, გამოცდილება.
• ღირებულებები და ხედვა
• პროექტის მენეჯმენტის მეთოდოლოგიები
•  ხარისხის მენეჯმენტი
• პროდუქტის გამორჩეულობა
• ტექნიკური დონე
• ფასები
•  გრძელვადიანი თავსებადობა და რისკის მენეჯმენტი - გასათვალისწინებელია ისეთი შემთხვევა, როცა მაგალითად მოგვიწევს კომპანიის შეცვლა, რამდენად მტკივნეული იქნება ეს საკითხი.

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

რათქმაუნდა თითოეული კრიტერიუმის ქვემოთ არის ქვე-კრიტერიუმები, რაც უნდა გაარკვიოთ გარკვეული კითხვების დასმით. 

მაგალითად 

რათქმაუნდა ეს არის უფრო ზოგადი ახსნა იმისა თუ როგორ უდნა შეარჩიოთ პროვაიდერი, ხოლო უფრო დეტალური ახსნისთვის, შეგიძლიათ იხილოთ ჩემი კურსი „how to choose a right provider”.

პროდუქტის განვითარების ფაზა - 16 საჭირო უნარები და გადაწყვეტილებები

ახლა ძალიან tricky topic_ი
რა ტიპის რესურსები გვჭირდება პროექტისთვის?
ეს არის

ყველა მათგანს აქვს პლუსები და მინუსები, განსაკუთრებით სტარტაპ მენეჯმენტის ჭრილში. 

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

შესასრულებელი სამუშაოსთვის საჭირო დრო კარგი ინდიკატორია ამ ნაწილში გადაწყვეტილების მისაღებად. 

ასე და ამგვარად, პირველ რიგში განვსაზღვროთ რა ტიპის რესურსები არის საჭირო DIGITAL PROJECT_ისთვის. 

მოდი დავიწყოთ პირველ რიგში PRODUCT OWNER_ით. 

ეს არის დამფუძნებელი, ყოველ შემთხვევაში დასაწყისში მაინც. 

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

სტრატეგიულ გუნდში, product owner-თან ერთად ასევე გვყავს project manager_ი. 

Project manager-ი პასუხისმგებელია roadmap-ზე სწორებაზე, ანუ არ უნდა გადაუხვიოს roadmap-ს. 

ეს არის ადამიანი რომელმაც უნდა იპოვოს გადაწყვეტები/he is in charge to find a solution. 

როცა პროექტი უფრო კომპლექსური გახდება, პროექტების მენეჯერი დაიხმარს IT ARCHITECT-ს. 

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

შემდეგ მოდის ოპერაციული გუნდი. 

User experience (creative)_ ეს ქმნის ბრენდის აღქმას,  - he creates the branding profile, he creates the entire customer`s experience. 

User interface - ეს არის ფოკუსირებული საბოლოო მომხმარებლების ქცევაზე. 

და ბოლოს დეველოპმენტის გუნდი.

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

და ასევე ეს შეიძლება განვიხილოთ როგორც ამ გუნდის მენეჯერი მომავალში. 

და დასასრულს მოდის ექსპერტების ნაწილი. 

ესენი შეიძლება დავიხმაროთ რომ შეხედონ პროექტს და თქვან თავიანთი ექსპერტული მოსაზრება იმასთან დაკავშირებით თუ თქვენ პროექტს თავიანთ კონკრეტული მიმართულებით რა განვითარება შეიძლება ჰქონდეთ, რას ხედავენ . მაგალითად რაში შეიძლება გამოგვადგეს AI ჩვენ პროექტში ან DATA SCIENCE ან სხვა მიმართულებები.

მოდი ახლა განვიხილოთ გადაწყვეტები თქვენი სტარტაპისტვის, 

დავიწყოთ 

Web agency-თ 

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

მინუსები:

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

რაც შეეხება freelancer-ებს. 

ესენი მარტივი სანახავია, მაგრამ უფრო სარისკოა სამართავად. 

პლუსები

მინუსები

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

IN HOUSE – internship and salaries. 

პლუსები

მინუსები

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

OFF SHORING

პლუსები: ისინი გაცილებით იაფი ღირს ვიდრე ევროპაში. 

მინუსები:

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

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

რომ შევაჯამოთ

ლოკალური რესურსები უფრო მარტივი გზაა

Nearshore- ითხოვს მეთოდოლოგიას და მიდგომას მათთან სამუშაოდ.

ხოლო offshore ითხოვს დროს და მეთოდოლოგიას.