Як выбраць каманду для распрацоўкі праграмнага забеспячэння
Пасля няўдалага праекта распрацоўкі праграмнага забеспячэння недастаткова проста знайсці іншую кампанію. Трэба зразумець, чаму першая каманда не дасягнула мэты, і выбраць партнёра, які можа паказаць, як ён пазбегне тых жа памылак. Праверце яго вопыт у падобных працэсах, папрасіце канкрэтны план, удакладніце, хто нясе адказнасць, і дамоўцеся, як вы будзеце прымаць кожную частку сістэмы.
Што трэба высветліць пасля няўдалага праекта?
Пачніце з кароткага ўнутранага разбору. Збярыце дагавор, прапанову, тэхнічную дакументацыю, доступы, код, дызайны і спіс абяцаных функцый. Адзначце, што сапраўды працуе, чаго не хапае і што ўжо не адпавядае вашым працэсам.
Не лічыце, што праблема толькі ў праграмаванні. Няўдалы праект часта пачынаецца з няяснага задання, зменлівых патрабаванняў, адсутнасці адказнага чалавека з боку кліента або абяцання выканаць працу ў фіксаваны тэрмін без дастатковай інфармацыі. Часам код добры, але няма інтэграцыі з бухгалтэрыяй, склад не адлюстроўвае рэальную працу або супрацоўнікі не могуць карыстацца сістэмай.
Падрыхтуйце спіс канкрэтных пытанняў: што змянілася падчас першага праекта? Хто ўхваляў рашэнні? Як прымаліся функцыі? Калі вы зразумелі, што тэрмін не будзе выкананы? Ці мелі вы доступ да кода і даных? Ці было тэставае асяроддзе і рэзервовыя копіі?
Якія пытанні задаць патэнцыйнай камандзе?
Першая сустрэча не павінна быць толькі прэзентацыяй партфоліа. Яна павінна паказаць, як думае каманда. Дайце ёй апісанне працэсу, які хочаце палепшыць, а не толькі спіс кнопак і экранаў.
- Якія часткі працэсу вы вывучылі б да таго, як прапанаваць тэхналогію?
- Як вы падзеліце праект на этапы, якія можна тэставаць і прымаць?
- Якія рызыкі вы бачыце ўжо цяпер і як вы іх праверыце?
- Хто будзе маім сталым кантактам і хто прымае тэхнічныя рашэнні?
- Як вы паступіце, калі падчас распрацоўкі высветліцца, што пэўная функцыя больш складаная, чым чакалася?
- Што я атрымаю пры перадачы: код, базу даных, дакументацыю, доступы і інструкцыі?
- Як апрацоўваюцца памылкі пасля запуску сістэмы?
Добры адказ не абавязкова будзе самым тэхнічным. Калі каманда гаворыць толькі пра мову праграмавання і дызайн, не пытаючыся пра ролі, ухваленні, рахункі-фактуры, склад, API і рэальных карыстальнікаў, верагодна, яна яшчэ не разумее задачу.
Як праверыць вопыт і партфоліа?
Паглядзіце партфоліа, але не спыняйцеся на прыгожых галоўных старонках. Шукайце праекты з падобнай логікай: кіраванне заяўкамі, ролі і правы, дакументаабарот, мабільныя каманды, плацяжы, склад, аўтаматычнае выстаўленне рахункаў або сувязь паміж некалькімі сістэмамі.
Напрыклад, LiftexPro — ERP для кампаній па абслугоўванні ліфтаў спалучае планаванне аглядаў, кіраванне будынкамі, мабільнае прыкладанне для тэхнікаў і аўтаматычнае выстаўленне рахункаў. Гэта больш паказальна для каманды, якая павінна стварыць бізнес-сістэму, чым агульнае абяцанне «ўнікальнай платформы».
Для працэсаў на аб'ектах паглядзіце таксама Ековат — ERP на заказ, дзе звязаны заяўкі, працоўныя карткі, аўтапарк, склад і дакументы. Пытанне не ў тым, ці адносіцца праект да вашай галіны. Пытанне ў тым, ці вырашала каманда праблемы падобнай складанасці.
Папрасіце паказаць дэманстрацыю працоўнай сістэмы, а не толькі здымкі. У дэма ERP для міжнародных перавозак можна ўбачыць рэйсы, кіроўцаў, аўтапарк, кліентаў, рахункі-фактуры, выдаткі і розныя віды для роляў у кампаніі. Так вы зразумееце, ці паказвае пастаўшчык рэальную логіку, ці толькі візуальную канцэпцыю.
Спытайце, якая частка паказанага з'яўляецца гатовым прадуктам, а якая распрацавана спецыяльна для канкрэтнага кліента. Папрасіце растлумачыць вашу ролю, выкарыстаныя інтэграцыі і абмежаванні. Не прымайце чужыя вынікі як доказ, калі каманда не можа растлумачыць сваю працу над праектам.
Як ацаніць тэхнічны падыход?
Тэхнічны падыход павінен пачынацца з працэсу і даных. Напрыклад, для CRM апісваюцца кліенты, здзелкі, прапановы, задачы, гісторыя камунікацыі і правы супрацоўнікаў. Для ERP удакладняюцца склад, продажы, рахункі-фактуры, справаздачы, ролі і сувязі з іншымі сістэмамі.
Папрасіце схему асноўных модуляў і патоку даных. Калі інтэрнэт-крама прымае заказ, як ён трапляе на склад? Калі ствараецца накладная? Як адлюстроўваецца плацеж? Што бачыць бухгалтар? Калі няма яснага адказу, праблема пазней праявіцца ў выглядзе ручной працы і памылак.
Праверце, як плануюцца інтэграцыі. API-сувязь з кур'ерам, аплатным аператарам, тэлефаніяй або бухгалтарскай праграмай — гэта не проста пункт у прапанове. Трэба ўдакладніць даныя, частату сінхранізацыі, памылкі, паўторную адпраўку і тое, хто будзе сачыць за сувяззю.
Спытайце пра тэставае асяроддзе, рэзервовыя копіі, журналы, правы доступу і спосаб публікацыі змяненняў. У сістэме з персанальнымі данымі абмяркуйце, хто мае доступ, як запісваюцца дзеянні і як аднаўляецца праца ў выпадку праблемы.
Як зразумець, ці будзе працаваць камунікацыя?
Камунікацыя вымяраецца не тым, наколькі хутка каманда адказвае да падпісання. Праверце, як вы будзеце працаваць пасля старту. Ці будзе штотыднёвая сустрэча? Дзе будуць запісвацца задачы? Як вы будзеце ўхваляць дызайн, працэс і гатовую функцыю? Як вы будзеце бачыць, што запланавана, а што заблакавана?
Прызначце чалавека са свайго боку, які ведае бізнес і можа прымаць рашэнні. Калі кожны супрацоўнік дае розныя ўказанні праграмістам непасрэдна, праект разгалінуецца. Новая каманда павінна мець адзін выразны канал для патрабаванняў і змяненняў.
Папрасіце прыклад справаздачы аб працы. Добрая справаздача паказвае, што завершана, што яшчэ трэба зрабіць, якія пытанні чакаюць рашэння і што ўплывае на тэрміны. Гэта больш карысна, чым агульнае паведамленне, што «праект рухаецца».
Як параўнаць тэрміны і бюджэт?
Не параўноўвайце толькі выніковыя сумы. Параўнайце, што за імі стаіць. Адна прапанова можа ўключаць аналіз, дызайн, распрацоўку, міграцыю даных, тэставанне, навучанне, публікацыю і падтрымку. Іншая можа ўключаць толькі праграмаванне.
| Што параўнаць | Пытанне да каманды | Рызыка пры адсутнасці адказу |
|---|---|---|
| Аб’ём | Якія функцыі ўключаны, а якія не ўваходзяць у прапанову? | Новыя выдаткі і спрэчкі падчас праекта |
| Этапы | Што мы атрымаем і прымем на кожным этапе? | Вы чакаеце да канца, каб убачыць праблемы |
| Даныя | Хто перанясе старых кліентаў, тавары і дакументы? | Страта інфармацыі або ручны ўвод |
| Інтэграцыі | Якія API-сувязі ўключаны і як яны тэстуюцца? | Сістэма ненадзейна абменьваецца данымі |
| Падтрымка | Як паведамляць пра памылкі і што не ўваходзіць у штомесячную паслугу? | Няма дакладнага адказу пры тэрміновай праблеме |
| Уласнасць | Дзе захоўваюцца код, даныя і доступы? | Залежнасць ад пастаўшчыка |
Для распрацоўкі праграмнага забеспячэння на заказ разліковы дыяпазон прапановы складае 3 000–29 300 €. Што вам прапануюць у гэтых рамках, залежыць ад колькасці модуляў, складанасці роляў, міграцыі даных, мабільнага прыкладання, інтэграцый, тэставання і патрэбы ў бесперапыннай падтрымцы. Не параўноўвайце ніжнюю мяжу адной прапановы з поўным аб’ёмам іншай.
Тэрмін таксама трэба звязваць з вынікам. Замест «гатова за кароткі час» папрасіце графік з этапамі, залежнасцямі і ўмовамі зацвярджэння. Калі вы затрымліваеце доступ, кантэнт або прыняцце рашэння, тэрмін павінен змяняцца празрыста.
Як павінен выглядаць працэс працы?
- 01Аўдыт старога праекта
Вы правяраеце наяўны код, базу даных, доступы, дакументацыю і нярэалізаваныя функцыі. Новая каманда апісвае, якія часткі можна выкарыстаць, а якія бяспечней перапрацаваць.
- 02Апісанне рэальнага працэсу
Вы расказваеце, як працуюць продажы, склад, бухгалтэрыя, палявыя супрацоўнікі і кіраўнік. Каманда перакладае гэты працэс у ролі, станы, даныя, апавяшчэнні і інтэграцыі.
- 03Пілотны аб’ём
Вы выбіраеце важную, але абмежаваную частку сістэмы. Яна павінна прайсці праз рэальны сцэнарый і паказаць, ці зручныя рашэнні для людзей, якія будуць імі карыстацца.
- 04Прыёмка па этапах
Для кожнай функцыі вы вызначаеце, што азначае «гатова». Вы тэстуеце яе на канкрэтных даных, запісваеце заўвагі і аддзяляеце дэфекты ад новых ідэй.
- 05Запуск і навучанне
Вы плануеце міграцыю, правы доступу, рэзервовыя копіі, навучанне і перыяд назірання. Не спыняйце старую працу, пакуль не будзеце ведаць, як дзейнічаць у выпадку праблемы.
- 06Падтрымка і развіццё
Вы ўдакладняеце канал для заявак, прыярытэты, рэакцыю на памылкі, абнаўленні і кошт дадатковых змяненняў. Так наступны этап не пачынаецца з новага пошуку пастаўшчыка.
Як пазбегнуць паўтарэння старых памылак?
Далучайце карыстальнікаў яшчэ да пачатку распрацоўкі. Супрацоўнік склада, дыспетчар і бухгалтар бачаць іншыя праблемы, чым кіраўнік. Кароткая дэманстрацыя на іх рэальным сцэнары можа выявіць недапрацоўку, якую доўгі спіс патрабаванняў не паказвае.
Не мяняйце пастаянна мэту, не ацаніўшы наступствы. Новая функцыя можа закрануць базу даных, ролі, API-злучэнні і тэрмін. Кожнае пашырэнне абсягу павінна мець апісанне, цану і ўплыў на графік.
Не пакідайце ўсё на ўзроўні вусных размоў. Фіксуйце рашэнні, узгадненні і адказнасць. У дамове ўдакладніце права ўласнасці на код, доступ да хостынгу і базы даных, канфідэнцыяльнасць, прыёмку і ўмовы скасавання.
Напрыканцы праверце, як выглядае падтрымка пасля запуску. Для існага сайта або сістэмы яна можа ўключаць абнаўленні, рэзервовыя копіі, праверкі і невялікія змены; для больш складанай ERP або CRM сістэмы спатрэбяцца маніторынг інтэграцый, кіраванне карыстальнікамі і развіццё функцыянальнасці.
Які выбар будзе правільным пасля няўдалага праекта?
Правільная каманда — не тая, што абяцае зрабіць найхутчэй і найтанней. Яна задае пытанні пра вашу працу, паказвае падобныя сістэмы, тлумачыць абмежаванні і дзеліць вялікую рызыку на невялікія рашэнні, якія можна праверыць.
Да падпісання вы павінны ведаць, хто працуе над праектам, што атрымаеце на кожным этапе, як прымаюцца функцыі, што будзе з кодам і данымі і да каго звяртацца пры праблеме. Калі гэтыя адказы зразумелыя ўжо на пачатку, верагоднасць паўтарыць стары сцэнар значна меншая.
Часта задаваныя пытанні
- Як зразумець, ці мае софтверная кампанія рэальны досвед?
- Папрасіце паказаць падобныя праекты, дэманстрацыю працоўнай сістэмы і растлумачыць, як каманда вырашыла канкрэтную бізнес-праблему. Партфоліа толькі са здымкамі дызайнаў не пацвярджае досведу ў інтэграцыях, ролях, даных і падтрымцы.
- Што рабіць з кодам з праваленага праекта?
- Правядзіце тэхнічны аўдыт, перш чым вырашаць, ці выкарыстоўваць код. Правяраюцца архітэктура, бяспека, база даных, дакументацыя, доступы і магчымасць іншай каманды падтрымліваць сістэму.
- Як вызначаецца кошт праграмнага забеспячэння на заказ?
- Кошт залежыць ад абсягу, колькасці модуляў, роляў, інтэграцый, міграцыі даных, мабільных прыкладанняў, тэставання і падтрымкі. Параўноўвайце не толькі выніковую прапанову, але і тое, што ўваходзіць у кожны этап.
- Як кантраляваць тэрмін распрацоўкі?
- Дамоўцеся пра этапы з канкрэтным вынікам і крытэрыямі прыёмкі. Сачыце за залежнасцямі, затрымкай рашэнняў і зменамі абсягу, бо яны непасрэдна ўплываюць на графік.
- Хто павінен удзельнічаць з боку кліента?
- Вызначце аднаго чалавека, які ведае працэсы і можа прымаць рашэнні. Да ключавых дэманстрацый далучайце і супрацоўнікаў, якія будуць штодня працаваць з сістэмай.
