- Чому польським підприємцям подобаються IT On-Premise системи? - 24 Вересня 2024
- Чи є низький код і відсутність коду лише варіаціями на одну тему? - 13 Березня 2023
- Чи система no-code не позбавить програмістів роботи ? - 1 Березня 2023
Реальність останнім часом дивує. Одна за одною на нас впливають ситуації, які «перевертають» існуючі припущення.
Це як нагромадження «чорних лебедів» із книги Нассіма Ніколаса Талеба.
Відповідно до теорії автора: “іноді трапляються речі, які – до того, як сталися – вважалися неможливими”. Однак у мене таке враження, що останнім часом таке «іноді» трапляється досить часто.
Не думаю, що мені потрібно переконувати тебе, що це також впливає на ваш бізнес.
Страховка на важкі часи
Звичайно, є способи підстрахуватися на так званий «про всяк випадок». На базі ІТ таке страхування включає в себе
Договір реалізації – тому що, можливо, доведеться відмовитися від проекту
Договір з компанією-реалізатором укладається перед початком будь-якої оплачуваної діяльності.
Найкраще, якщо це передбачає співпрацю на умовах Scrum + Time & Material. Це означає, що ти самостійно обираєш завдання, які виконує команда розробників. Ти платиш лише за час і ресурси, використані під час виконання завдання. Наступний функціонал додається до системи кожні 2 тижні.
При необхідності – можеш в будь-який момент змінити напрямок реалізації, встановити інший пріоритет під конкретні завдання і навіть зупинити роботу, поки не буде знайдений бюджет. Важливо, що за укладеним договором – система в поточному стані залишається у твоєму повному розпорядженні.
Аналіз перед впровадженням – тому що команді проекту треба краще взнати твій бізнес
Перед початком роботи необхідно зустрітися з аналітиком на спеціальному воркшопі. Це дає змогу зрозуміти бізнес-процес клієнта та визначити найважливіші потреби, які мають бути відображені в системі. Таким чином ти захистиш себе від непорозумінь і краху всього підприємства.
Висновки зустрічі будуть використані для створення т. зв Белог продукту; просторіччям – сумка з ідеями щодо функціональності твоєї системи. Використовується при виконанні робіт. Ти також можеш постійно організовувати, змінювати та розширювати його відповідно до своїх поточних уподобань. Серед іншого, у разі чергового «чорного лебедя».
Scrum – тому що тобі, можливо, доведеться щось змінити в процесі
Як співпрацювати з IT-компанією, коли тобі загрожує черговий «чорний лебідь»?
Найкраща стратегія – «швидкість» підходу, адаптація до умов, що змінилися, толерантність до змін як до чогось природного в середовищі. Одним словом: agile.
Типовим способом організації роботи за методологією aglie є Scrum. Від усієї душі рекомендую!
Тоді тобі не доведеться чекати на документацію системи, якої ще немає. Робота над проектом починається негайно. Після перших 2 тижнів (зазвичай одна ітерація в Scrum) ти отримуєш перші функції для тестування. Ефекти можуть навіть відразу потрапити в “виробництво”.
Scrum також організовує роботу всієї Команди. Твоя як координатора продукту та всі інші залучені люди. Програмісти беруть участь у численних зустрічах і постійно піклуються про високу якість коду, що поставляється. Ти також отримуєш підтримку проксі-власника продукту, тобто аналітика, який познайомився з вашим бізнесом під час аналізу перед впровадженням.
А якщо потрібно щось вдосконалити – така можливість завжди є!
Як і в житті, у проектах Scrum зміни є природними. Може знадобитися через появу іншого «чорного лебедя». Але це також може бути просто результатом висновків, зроблених командою. Масштаб такої зміни довільний. Scrum це гарантує!
Час і матеріали – адже краще знати, за що платиш
Я вже втягнув цю інформацію, але вирішив, що варто, щоб вона прозвучала прямо. Ще один спосіб захистити свої інтереси – це Time & Material.
Я маю на увазі виставлення рахунків лише за час і ресурси, витрачені на проект. Звісно, з урахуванням кошторису та верхньої межі бюджету.
Звичайно, може трапитися так, що ти заплатиш за деякі функції більше, ніж очікувалося спочатку. Зрештою, це лише припущення. Але ти дізнаєшся про це не з рахунку в кінці місяця, а поступово, з системи оформлення та повідомлень в електронну скриньку. Крім того, саме Власник продукту разом із довіреним Власником продукту спільно вибирають питання, які потрібно реалізувати, і контролюють, скільки це коштує. Ніщо не може вислизнути від твоєї уваги.
Oczywiści może się też zdarzyć, że zapłacisz mniej. 😉
Testy funkcjonalne – bo lepiej mieć pewność, że wszystko działa jak należy
Po latach pracy w eVolpe ten etap wydaje mi się bezdyskusyjny.
Trudno mi wyobrazić sobie firmę IT, która nie testuje wytworzonego kodu. Taka praktyka nazywa się Code Review. Chodzi o to, żeby sprawdzić, czy te wszystkie znaczki, które dla mnie nadal pozostają tajemne, a decydują o funkcjonalności narzędzia, zapisano w optymalny sposób. Tak zwane ce-erki zwykle wykonują starsi stażem programiści, którzy mają większe szanse zauważyć ewentualne niedociągnięcia.
Poza kodem powinno się testować także samą funkcjonalność. Do tego celu zatrudnia się testerów oprogramowania. „Klikają” oni po specjalnej testowej instancji, porównują User Story z efektem pracy programisty i szukają potencjalnych błędów, aby zgłosić je do poprawy.
Ostatnia rzecz to wypróbowanie systemu przez Product Ownera lub wyznaczonego do tego celu użytkownika aplikacji. Dzięki temu masz 100%-ową pewność, że otrzymujesz to, o co prosisz.
W sytuacji, w której innych zaskakuje niespodziewany „czarny łabędź” – Twój system pozostaje niezawodny. W końcu przetestowano go aż na trzy sposoby.
Szkolenia dla użytkowników – bo sam system niczego nie zmienia, jeśli z niego nie korzystacie
Zwykle po albo tuż przed startem produkcyjnym odbywają się szkolenia dla użytkowników i administratorów. Jest to etap nieobowiązkowy, ale zdecydowanie przeze mnie rekomendowany.
W ten sposób pracownicy Twojej firmy poznają funkcje dostarczonego oprogramowania. Dzięki szkoleniom ułatwiasz im przystosowanie się do nowego sposobu pracy (user adoption). A im szybciej nauczą się z niego korzystać, tym szybciej zauważysz zwrot z podjętej inwestycji.
W sytuacji, w której nadejdzie kolejny „czarny łabędź” – będą też odpowiednio uposażeni, by skorzystać z funkcjonalności oprogramowania w celu ratowania firmy przed niepożądanymi skutkami gwałtownych przemian.
Service Level Agreement – bo może będzie trzeba rozbudować gotowy system
Po zakończonym wdrożeniu przychodzi czas na utrzymanie poprawnego działania instancji w zatwierdzonym stanie oraz dalszy jego rozwój na podstawie umowy serwisowej lub nowego zlecenia. Odbywa się to na zasadach określonych w umowie SLA.
To kolejny rodzaj ubezpieczenia na ciężkie czasy. Jeżeli sytuacja na rynku zmieni się po Go-Live systemu, niezbędnych zmian będzie w nim można dokonać na zasadach określonych w umowie serwisowej.
Zwykle przysługuje Ci pakiet godzin do zrealizowania. Firma wdrożeniowa gwarantuje gotowość bojową. Rezerwuje czas programistów, by się wywiązać z obietnic.
Do Ciebie należy dysponowanie zasobami w efektywny sposób. W tym celu możesz zlecać dowolne zadania i to w ilości, na jaką pozwoli suma godzin do wyczerpania w miesiącu.
Współpraca powdrożeniowa do złudzenia przypomina więc etap prac implementacyjnych, ale dla porządku objęta jest osobną umową. A to dlatego, że zwykle spada częstotliwość zgłaszanych przez Ciebie potrzeb.
Gdyby coś się wydarzyło – wszyscy są jednak gotowi podjąć działania.
Open Source – bo system powinien być elastyczny
Na koniec argument koronny. Otwarty kod oprogramowania.
Kiedy obawiasz się niestabilnej sytuacji na rynku – Twój system powinien być elastyczny. Musisz być w stanie dokonać w nim dowolnych usprawnień.
Open Source Ci to gwarantuje. Jeśli programiści mają możliwość ingerencji w kod systemu – każda modyfikacja będzie możliwa.
Nie pozbawiaj się tej szansy. W samej ofercie eVolpe znajdziesz mnóstwo takich systemów do wyboru. Przyjrzyj się na przykład:
Jeśli masz dodatkowe pytania, nie wahaj się. Eksperci eVolpe czekają, aby przeprowadzić indywidualną konsultację na ten temat. Kalendarz wolnych terminów znajdziesz poniżej.
Зареєструйся на консультацію з експертами по впровадженню eVolpe
- Чому польським підприємцям подобаються IT On-Premise системи? - 24 Вересня 2024
- Чи є низький код і відсутність коду лише варіаціями на одну тему? - 13 Березня 2023
- Чи система no-code не позбавить програмістів роботи ? - 1 Березня 2023