## Six Reasons Why Project Documentation Makes Project Development Smoother

During the early stages of my career as a project manager in a web agency, I discovered an untold secret that seemed to go unnoticed by many: the lack of proper analysis in most projects. Furthermore, with it, clients could receive comparable price quotes that differentiated one from another and could be analyzed by more experienced individuals.

>Would you order house price quotes and construction without a project?

In simplified terms, the usual process from the client's perspective works as follows: the client meets with the developer and provides a general description of what they expect. The developer asks for various clarifications, and the client responds. The process is repeated with the second, third, and perhaps even fourth developer. The questions and proposals were different, and consequently, the responses to the developers were always different. In this case, how can one expect the price offered by developers to be comparable or produce the same result that the client expects? How can one assume that the work provided by each developer will yield the same outcome? How can one adequately assess the quality or price of the proposals when the initial information is different for everyone, and each developer has added something of their own?

This development process always resulted in the client asking questions at the end of the project, such as "Aren't you doing this or that?" or "I thought it would work like this." Mainly because a) the client needed to sufficiently describe their vision, which needed to be clearly stated, and b) the client discussed functionality with one developer but not with the one they commissioned the work. A good idea that was discussed remained unacknowledged in the initial documentation.
The aftermath of such a dispute left the client and the developer dissatisfied, as the process was unpleasant for both parties. Instead of referring to documentation or a project plan during the execution of the work, disputes arose based on unspoken or undocumented client expectations. Or conflicts arose because the developer did not understand the client's descriptions or needs.

Below, I will explain how conducting a detailed analysis for each project can improve the development process for all parties involved.

## You can receive comparable price quotes.

Only when you share the same information with all development service providers can the solutions they offer be compared. All the questions and proposals they present can also be answered and documented in the initial documentation. This way, all the new thoughts and ideas are shared among all service providers.

Just as you would only request house construction quotes with a project, it is always wise to thoroughly and precisely document your project. Otherwise, how can you receive price quotes that ensure the work will yield the same result?

## Changing development partners becomes more manageable.

A problem that IT agencies often encounter when talking to a client who wants the developed project to be taken over by a new developer is the need for more documentation for the project. If there is documentation for the project, transferring the project becomes simple because the new developer needs to know how the project should precisely function, the client's current needs, and what problems the project should solve. The client must repeat everything that has been previously discussed since the requirements are undescribed and undocumented. Telling the developer to "see how the current solution works" is useless and dangerous because looking at the code does not clarify what is good or bad in the old solution. What is a bug, and what is not? I once found myself in the role of a project manager in such a situation. I did not ask for documentation and requirements and chose to proceed with development, eventually creating a problem that I could have avoided for everyone involved.

However, if the client has documented all the project requirements, they can easily change development partners. If, in addition, it is also required that tests cover the developed functionality, it becomes even more straightforward. Time and time again, I see clients who come to me with a story about conflicts with their development partners, and I must admit that we need to start with documenting the project and describing the requirements.

## Ordering new developments becomes easier.
Even if you successfully cooperate with an existing development partner, you benefit significantly from documenting your needs and requirements. There may be months or years between different developments. But if you require a new feature developed or changed, you can always refer to the documentation to see the current status, future status, and what the necessary change entails.

The documentation is also essential because employees in development companies change, and with such documentation, it becomes easier for a new employee to get into the system. With documentation, however, you are likely to save time in development.

## The client benefits from development speed, cost, and quality.

When the system's functioning is well thought out and documented, there are fewer surprises for the development price provider, which means you can receive clearer, cheaper, and better-thought-out price quotes. This applies to ordering both new developments and making changes to existing applications. Your employees may change as well, and they will find it easier to delve into the project and communicate with the development partner if your application requirements are documented.

## The client has a better overview of the development progress.

You can compare your documentation and requirements at any given moment with what has already been accomplished. Or even better, have the developer keep that overview up to date for you.

## You have a foundation document for user testing.

A proper description of requirements also serves as a sound basis for testing the application, whether performed by the developer or a third-party service purchased for that purpose. In both cases, it is possible to take the description of functionalities from the documentation - the same for everyone - and see if the solution works as described. It also makes it easy to identify problems and inconsistencies in the documentation systematically.

## I can assist you in compiling such documentation.

Throughout my work experience, I have worked on various clients' development needs and compiled project documentation. I have also done the same work as a consultant. Fortunately, many clients have recognized and appreciated the value of creating such documentation.


## Kuus viisi, kuidas projekti dokumentatsioon teeb projekti arenduse sujuvamaks.

Oma karjääri algusperioodil, kui alustasin tööd projektijuhina veebiagentuuris avastasin rääkimata saladuse, mille peale nagu keegi ei näinud mõtlevat ja defineerisin probleemi. Nimelt puudus enamikul projektidel korralik analüüs. Veelgi enam, ilma selleta ei olnud klientidel võimalik saada võrreldavaid hinnapakkumisi, mis selgelt eristuksid üksteisest ja mida oleks võimalik vähem asjatundlikumatel analüüsida.

>Kas sina telliksid maja hinnapakkumised ja ehituse ilma projektita?

Lihtsustatult kirjeldades toimib tavapäraselt protsess kliendi vaatevinklist järgmiselt; klient kohtub arendajaga ja annab talle üldise kirjelduse selle kohta, mida ta ootab. Arendaja küsb erinevaid täpsustusi ja klient vastab. Sama ka teise ja ehk veel kolmanda ja neljanda arendajaga. Küsimused olid teised, ettepanekud teised ja sellest tulenevalt ka vastused arendajatele olid alati erinevad. Kuidas, saab sellisel juhul eeldada, et töö, mida iga arendaja pakub annab sama tulemuse? Kuidas saab adekvaatselt hinnata pakkumiste kvaliteeti või hinda, kui alginfo pole kõigil sama ning kõik arendajad on sinna midagi juurde mõelnud.

Sellele järgnev arendusprotsess päädis alati sellega, et klient hakkas projekti lõpus esitama küsimusi stiilis “kas te seda ei teegi või”, “ma arvasin, et see toimib nii”. Enamjaolt seepärast, et a) klient ei olnud kirjeldanud oma nägemust piisavalt hästi ja see ei olnud kirjeldatud selgelt b) Klient arutas funktsionaalsust ühe arendajaga, kuid mitte sellega, kellelt töö tellis. Hea idee, mida arutati, jäi algdokumentatsioonis üles tähendamata. 

Sellise vaidluse järe ei olnud rahul ei klient ega arendaja, kelle mõlema jaoks oli protsess ebameeldiv. Selle asemel, et viidata tööde teostamise raames dokumentatsioonile või projekti plaanile, tekkisid vaidlused lähtuvalt kliendi rääkimata või dokumenteerimata ootustest. Või tekkisid vaidlused sellest, et arendaja ei olnud aru saanud kliendi kirjeldustest või vajadustest.

Selgitan allpool lahti, kuidas igale projektile detailse analüüsi tegemine aitab sul projekti arenduse protsessi kõigi osapoole jaoks paremaks teha.

## Sul on võimalik saada omavahel võrreldavaid hinnapakkumisi

Ainult siis, kui kõikidele arendusteenuse pakkujatele jagada sama info on sul pakutavad lahendused omavahel võrreldavad. Kõik küsimused ning ettepanekud mida nad esitavad saab samuti vastatud ja dokumenteeritud algses dokumentatsioonis - selliselt on kõikide teenuse pakkujate vahel jagatud ka kõik tekkinud uued mõtted ja ideed. 

Nagu ei hakkaks sa kunagi võtma maja ehituse pakkumisi ilma projektita on alati mõistlik ka oma projekt korralikult ja detailselt dokumenteerida. Kuidas muidu saad sa hinnapakkumisi, mille alusel teostatud töö annab sulle täpselt sama tulemuse? 

## Arenduspartneri vahetamine on lihtsam.

Probleem, mida IT agentuurid tihti näevad, kui nad satuvad rääkima kliendiga, kes soovib, et arendatud projekt võetaks uue arendaja poolt üle, on see, et projektil puudub dokumentatsioon. Kui projektil see puudub, siis on projekti üle võtmine keeruline, sest uus arendaja ei tea KUIDAS täpselt peab projekt töötama, millised on praegused kliendi vajadused ja probleemid mida projekt lahendama peab. Klient peab kõike juba kunagi räägitut uuesti kordama, kuna vajadused on kirjeldamata ja dokumenteerimata. Öelda, arendajale, et “vaata, kuidas praegune lahendus töötab” on kasutu ja isegi ohtlik, sest koodile otsa vaadates ei ole selge, mis on vanas lahenduses hea või halb. Mis on bugi ja mis mitte. Kord olin ise projektijuhi rollis sellises seisus ja tegin vea, loobudes dokumentatsiooni koostamise nõudmisest ja tekitasin lõpuks olukorra, mis kõigi jaoks halb oli.

Kui kliendil on aga kogu projekti vajadused dokumenteeritud on kliendil ka märksa lihtsam arenduspartnerit vahetada. Kui lisaks sellele on  nõutud ka, et arendatud funktsionaalsus oleks testidega kaetud on see veel lihtsam. Ikka ja jälle näen ma kliente, kes jõuavad minu juurde jutuga, et arenduspartneriga on suusad ristis ja mina pean nentima, et alustame projekti dokumenteerimisest ja vajaduste kirjeldamisest.

## Uute arenduste tellimine on lihtsam

Ka juhul, kui sa teed edukat koostööd olemasoleva arenduspartneriga on sul palju kasu sellest, kui sul on vajadused ja nõuded dokumenteeritud. Erinevate arenduste vahel võib teinekord olla kuid ja aastaid. Aga kui sul tekib vajadus uue arenduse järgi või muudatuse järgi on sul võimalik alati viidata dokumentatsioonis sellele, milline on praegune seis, milline on tuleviku seis ja milles seisneb vajalik muudatus. 

See on oluline ka seetõttu, et ka arendusettevõttes vahetuvad töötajad ja sellise dokumentatsiooni puudumisel on uuel töötajal väga keeruline minna sisse süsteemi. Dokumentatsiooni olemas olles võidad aga sa suure tõenäosusega arenduse ajas. 

## Klient võidab arenduse kiiruses, hinnas ja kvaliteedis

Kui süsteemi toimimine on läbi mõeldud ja dokumenteeritud on arenduse hinna pakkujal vähem ootamatusi, mis tähendab, et sul on võimalik saada selgemaid, odavamaid ja paremini läbi mõeldud hinnapakkumisi. See on nii, nii uue arenduse, kui ka olemasolevale rakendustele muudatuste tellimisel. Ka sinu töötajad võivad vahetuda - ka neil on lihtsam projekti süveneda ja arenduspartneriga suhelda - kui sinu nõuded rakendusele on dokumenteeritud.

## Kliendil on parem ülevaade arenduse käigust

Sul on igal hetkel võimalik võrrelda oma dokumentatsiooni ja vajaduste kirjeldusi sellega, mis on juba ära tehtud. Või, mis veelgi parem, lasta arendajal sinu jaoks seda ülevaadet ajakohasena hoida.

## Sul on alusdokument kasutustestidele.

Korralik vajaduste kirjeldus on ka hea alus rakenduse testimisele. Tehku seda siis arendaja või on see sisseostetud kolmanda osapoole teenus. Mõlemal juhul on võimalik võtta dokumentatsioonist funktsioonide kirjeldus - mis on sama kõigile - ja vaadata, kas lahendus toimib nii, nagu kirjeldatud on. Samuti on siis lihtne süsteemselt välja tuua probleeme ja mittevastavusi dokumentatsioonile.

## Mina saan sind sellise dokumentatsiooni kokkupanemisel aidata.

Olen erinevatel töökohtadel läbi töötanud paljude klientide erinevaid arendusvajadusi ning kirjutanud kokku projektide dokumentatsioone. Sama tööd olen teinud ka hiljem, konsultandina. Õnneks on nii mõnedki kliendid seda dokumentatsiooni loodud väärtust näinud ja hinnanud.

if you want a successful IT project, do proper preliminary work and create project documentation.

kui sa tahad edukat IT projekti, tee korralik eeltöö ka loo projekti dokumentatsioon.

If You Want Your IT project to go Smoothly and Succeed, Start With the Documentation.

Kui tahad, et su It projekt laabuks ja oleks edukaks, alusta projekti dokumentatsioonist

## 1. Is your project the right size for your partner?

Whenever I hear about different problems which companies have with their clients, one that often comes up is - they rarely speak to me. Or - It seems like they don't care enough. Or - It looks like they are not trying any more.

There are only so many projects one project manager can successfully handle, which means they are the real limiting factor for the dev shop, not the programmers. The project managers also face pressure from the company to do the things that bring in the most money. The result is that you do not receive the attention you deserve.

There are, however, ways to overcome this kind of problems:
-  Pick the developer for whom you are the big client. Look at what they have done before and if your project seems to be a big one (but not too big) compared to what they have in their portfolio, then choose them. Do not pick a development partner for whom your project is small.
-  Develop project in phases. Accept that we are not infallible and make mistakes - bugs happen. If you gather all your issues into one extensive list and present the list in one email or call, you'll likely get more attention. Not because you brought a long list of issues to their attention, but because you saved their time and gave them work for a more extended period. If you add the following development phase requirements to the list of issues, then you'll receive even more attention.

## 2. Pick a team with up-to-date and proven technologies

One of the problems which some clients face is that they cannot find another development partner to continue the work of the previous one. Sometimes, the problem stems from the fact that the last partner's code is poor, and no new partner wants to pick it up because it is challenging to estimate the number of hidden problems in the code. Which in turn might result in loss of turnover for your new partner.

How you can overcome this problem is simple if you have a technical background but quite tricky if you don't. One way to estimate if the technologies your potential partners offer is to look at popular surveys [like Stack Overflows yearly overviews](https://insights.stackoverflow.com/survey/2020#technology). If the tools your partner wants to use are popular, then it is likely that they have plenty of support from the community and are easy to use. Popular tools also mean that you potentially can easily continue the current work with a new partner, should the need arise.

## 3. Does your new partner plan for quality or failure?

Look for code quality in the estimate. Does your partner plan to spend time on writing automated tests or user testing? Do you, after reading the quote, understand who is responsible for the code quality. If you don't, then this very likely means that discovering bugs might be your problem.

The problems with the code, mostly known as bugs, result from our inability to hold the complete picture of complex systems in our mind. While programmers are often very systematical thinkers, none can bear the whole complex system in their mind and consider how potential changes affect the entire ecosystem. Bugs happen when different moving parts of the project don't work well together. It's nobody's fault. Most people can't follow relatively simple recipes without mistakes - or assemble IKEA furniture. So why should we think that bugs mean bad programmers?

We know that the bugs WILL happen. What you, as a customer, need to pay attention to is if your new partner has a plan in place for handling them. What to look for in the quote:

- Look for automated testing. Automated testing means that you will periodically test the essential bits of your project against code to make sure that your functionality remains intact. Thus automated makes noticing breaking changes quite simple.
- Look for CI/CD (Continuous Integration / Continuous Delivery), QA (Quality Assurance). Lines like these in your quote means that the development team has a history of ensuring project quality. CI means automated procedures to ensure project quality. CD means that the deploys of new code are automatic and save you time and money down the line, and QA implies that they have set some resources by for different things like code reviews, user testing and so on.

In this book, "The Black Swan", Nassim Nicholas Taleb describes this example. What if a hypothetical politician had pushed for safety doors for plane cockpits in 2000? And what if all planes had safety doors installed before September 2001? The 9/11 would not have happened, but all plane manufacturers would have blamed the previous hypothetical politician for wasting their time and money. It's the same with tests. We, as customers ordering the service, have no idea how many catastrophes quality assurance prevents. We look at the numbers of money spent and often think - is it even necessary. It is. If it's not present in the quote given to you, then expect trouble in the future.

The actual amount of tests per project varies from project to project. Like implementing a Content Management System to your design, some projects might not even need custom automated testing as CMS comes with their internal tests.

## 4. Do they offer to monitor website issues?

Every web project will have problems. There are just so many moving parts out of the control of you and the development partner. Services might fail and break etc.

It is not possible to ensure that some third party service is up and running. But you can control, how your project will behave if that service breaks down. What they can control is who finds the bugs and problems - you, your customers or them? There are plenty of automatic tools out there, which notify developers of errors in the website. Make sure your development partner is using them on your project. You want to make sure the errors are found as fast as possible, right?

## 5. Do they have a plan for handling technical debt?

First, it is essential to understand what is technical debt. Everything degrades, right? You have mileage or time-based service intervals for your car. Your Windows or Mac computer receives updates now and then. Why would you think your project needs no updates?

Web projects have become so complex these days. Fifteen years ago, everybody was still developing their own CMS's, and when they built a website, the website consisted of only one or two pieces of software. These days things are very different. This straightforward website here is made with [NextJS](https://nextjs.org/) (plus [Strapi](https://strapi.io/), [TailwindCSS](https://tailwindcss.com/) and many more tools) and consists of more than 50 third-party projects. Somebody needs to keep them all up to date. Because if nobody updates the software, then adding new features or fixing issues will become increasingly difficult. It is much cheaper and easier to update project gradually than once per year. If you have automatic tests in place (see previous point #4), then updating is even easier - another point into the long list of why ensuring project quality is essential.

So the bottom line - if you gradually spend time and money on keeping your project up-to-date, then adding new features or handling the project over to another partner will become much cheaper and easier in the long run. It is potentially saving you from having to re-write the whole project in 3 to 5 years.

## All this is hard

Technology changes these days rapidly. It is challenging to keep up, and it is even more challenging to keep up for people who do not deal with project ownership daily.

When you assign the project owner role to a person in your company, you might be setting yourself up for failure. All these points, and many more, are pretty easy to explain to management if you know about them. Project owners, whose prominent role is not project owner, often do not have this ability. Your company and project will be missing out on all the benefits your partners may want to offer to you. To get more out of your project and your development partner [contact me](/contact/) or someone like me.

## 1. Kas sinu projekt on sinu partneri jaoks õige suurusega?

Kui ma kuulen kaebeid arenduspartneri kohta, siis need on tihti sarnased: "nad räägivad minuga harva", "tundub, et nad ei hooli piisavalt", "ma ei tea, mida nad praegu teevad".

Üks projektijuht saab hästi ja edukalt hallata piiratud arvu projekte, mis tähendab, et just nemad on agentuuri jaoks tihti limiteeriv faktor. Ka ettevõtte juhtkond paneb projektijuhtidele surve teha asju, mis toovad sisse kõige rohkem raha. Tulemuseks on pahatihti see, et kliendid ei saa piisavalt tähelepanu. 

Sellest on võimalik üle saada kahel viisil:

- Vali partner, kelle jaoks sa oled suur klient. Vaata, milliseid töid on nad teostanud varemalt ja kui sinu projekt võiks olla nende jaoks suur ( kuid mitte üleliia suur), siis vali neid. Ära vali partnerit, kelle jaoks sinu projekt on pisiasi, siis nad ei pinguta tõenäoliselt sinu töö pärast piisavalt.
- Arenda projekti osade kaupa. Aktsepteeri, et keegi ei ole täiuslik ja kõik teevad vigu. Bugisid ikka tuleb ette. Kui sa kogud kõik tööd/probleemid ühte listi, siis on tõenäoliselt projektijuhil sinu jaoks rohkem aega - sest töid ei tilgu ükshaaval peale ja ta saab süveneda korraga paljudesse asjadesse. See on kõigi jaoks efektiivsem. Kui sa lisad selle listi juurde veel järgmise arendusfaasi info, siis saad nende käest kindlasti veelgi rohkem tähelepanu.

## 2. Vali meeskond tänapäevaste ja laialt kasutusel olevate tehnoloogiatega.

Üks probleem, mida arendust tellivad kliendid komistavad on see, et nad ei leia arenduspartnerit, kes tahaks üle võtta eelmise arenduspartneri töö. Mõnikord on see põhjendatud sellega, et varasema partneri töö kvaliteet oli kehv ja uus partner ei taha seda üle võtta, sest koodis võib esineda ootamatusi, millega keegi arvestada ei oska. Mis tähendab suure tõenäosusega kahjumit uue partneri jaoks. Tihti on aga põhjuseks see, et tehnoloogiate valik ei olnud pädev ja valitud tehnoloogiad on kas aegunud, pole veel laialdaselt levinud (mis tähendab, et arendajaid on keeruline leida) või lihtsalt ebasobivad.

Sellistest probleemidest ülesaamine on tehnilise taustaga inimesele võrdlemisi lihtne, kuid päris keeruline, kui sul seda ei ole. Üks viis hinnata tehnoloogiaid, mida su potentsiaalsed partnerid plaanivad kasutada vaadates populaarseid küsitlusi nagu [Stack overflow igaaastane ülevaade](https://insights.stackoverflow.com/survey/2020#technology). Kui tööriistad ja tehnoloogiad, mida su partner plaanib kasutada on populaarsed, siis on tõenäoline, et neil on üle maailma piisavalt kasutajaid ja tuge ning need on lihtsad kasutada. Populaarsed tööriistad tähendavad ka seda, et praeguse parnteri töö võib võrdleimisi lihtsalt üle võtta järgmine partner - kui selleks peaks põhjus tekkima.

## 3. Kas su partner plaanib kvaliteeti pakkuda või plaanib läbi kukkuda?

Vaata hinnapakkumises asju, mis viitavad kvaliteedile. Kas su partner on välja toonud testide kirjutamise? Kas sa saad peale hinnapakkumisega tutvumist aru, kes vastutab tulemuse kvaliteedi eest - kas testimine on teenuse pakkuja poolt või jäetakse tellija hooleks? Kui ei, siis tõenäoliselt eeldab partner, et bugide avastamine jääb sinu hooleks. 

Probleemid koodis tulevad tihti sellest, et ükski arendaja ei suuda kõige peale mõelda ja terve süsteemi detaile oma mälupildis hoida. Kuigi arendajad on enamasti väga süsteemsed mõtlejad ei suuda pea ükski neist kohe öelda või mõelda, kuidas mingi muudatus tervet süsteemi mõjutab. Nii juhtuvadki bugid, kui süsteemi erinevad liikuvad osad enam hästi kokku ei tööta. Enamasti ei ole see kellegi süü. Suur osa inimesi ei suuda IKEA mööblitki manuaali järgi kokku panna - miks siis arvata, et bugide tekkimine tähendab halbu arendajaid.

Me teame et bugisid tuleb ette. Mida sina kliendina pead jälgima, kas sinu arenduspartneril on plaan nende leidmiseks, vältimiseks ja nende parandamiseks. Pööra pakkumises tähelepanu järgmisele:

- Vaata kas midagi viitab automaatsetele testidele. Automaattestid tähendab  seda, et sul on kirjutatud jupid koodi, mis testivad teiste koodijuppide veatut tööd. Mida automaattestid sinu jaoks tähendab on see, et uute featuuride lisandumisel püüavad need kinni võimalikud tekkivad vead. Nii ei pea sina bugisid avastama.
- Vaata kas midagi viitab Terminitele CI/CD (Continuous Integration, Continuous Delivery) või QA ( Quality Assurance). Mida see sinu joaks tähendab on see, et projekti käigus plaanitakse kasutusele võtta automaatseid tööriistu või muid protsesse tagamaks kvaliteeti. CI tähendab erinevaid automaatseid protsesse erinevate probleemide tuvastamiseks. CD - automaatset koodi serverisse paigladamist, kui muud automaatkontrollid on läbitud ja QA tähendab erinevate resursside nagu koodi revjuud, kasutaja testid jm. kasutamist tagamaks projekti kvaliteeti.

Oma raamatus "The Black Swan" kirjeldab Nassim Nicholas Taleb üht juhtumit. Mis oleks, kui enne 2000 aastat oleks mõni poliitik suutnud läbi suruda selle, et kõikidel lennukitel peavad olema lenduri kabiini uksed turvalised. Kui see oleks juhtunud enne septembrid 2001 oleks tõenäoliselt kakskiktornid püsti. Kõik lennuki tootjad oleks samas seda hüpoteetilist poliitikut siunanud nende raha raiskamisese pärast. Sama lugu on kvaliteedi kontrolli ja automaat testidega. Meie klientidena ei tea ega tunneta, kui palju meie raha ja aega säästab või katastroofe ära hoiab automaat testide kasutamine. Kui me vaatame vaid rahanumbreid, siis me mõtleme, et kas see on üldse vajalik. Täiesti kindlasti - on küll. Kui sellega ei ole pakkumises arvestatud, siis võid kindel olla tulevikus probleemide tekkimises.

Kui palju iga projekti jaoks teste vaja on - see sõltub projekti olemusest. Kui projekt on lihtsalt kujundusest disaini või välisveebi tegemine, siis tõenäoliselt ei ole neid üldse vaja, sest enamik sisuhaldussüsteeme omab omi, sisseehitatud, teste.

## 4. Kas nad pakuvad veebiteenuste jälgimist?

Igas veebiprojektis tekivad mingid probleemid. Neis on tihti lihtsalt niivõrd palju liikuvaid osi mida sina või sinu partner kontrollima ja haldama peavad. Teenused võivad maha kukkuda jne.

Tihti ei ole võimalik kontrollida kas mõni kolmanda osapoole teenus on püsti või ei. Aga on võimalik kontrollida, kuidas teie projekt käitub, kui midagi läheb katki. Kas sinu partner on arvestanud sellega, et mingid teenused võivad kokku joosta või maha kukkuda. Kas sa saad pakkumisest aru, kes peab märkama, kas veeb toimib või ei? Ka selleks on olemas palju automaatseid tööriistu. Tee endale selgeks, kas sinu partner plaanib neid kasutada - sa ju tahad, et kõik probleemid avastakse võimalikult kiiresti, eks?

## 5. Kas neil on plaan tehnilise võlaga tegelemiseks?

Kõigepealt - mis on tehniline võlg? Kõik laguneb, eksole? Su autot on vaja iga aasta hooldada, samuti sinu arvutit. Sinu arvuti tõmbab kogu aeg uuendusi alla. Miks peaks arvama, et sinu veebiprojekt ei vaja uuendusi?

Tänapäeva veebiprojektid on väga kompleksed süsteemid. 15-20 aastat tagasi arendasid kõik oma sisuhaldussüsteemi nullist, kui arendati veebilehte ja veebileht koosnes vaid mõnest erinevast süsteemist. Tänapäeval on asjad väga palju erinevad. See võrdlemisi lihtne veebileht, mida sa praegu külastad on tehtud [NextJS](https://nextjs.org/) (plus [Strapi](https://strapi.io/), [TailwindCSS](https://tailwindcss.com/) ja paljude teiste tööriistade abiga ja kasutab rohkem, kui 50 erinevat alamprojekti. Kõiki neid pakke peab erinevatel põhjustel uuendama. Sest, kui keegi seda ei teeks, läheks uute featuuride arendamine mingi hetk väga kulukaks - sest tol hetkel tuleks seda kõike teha. Seetõttu on veebilehte pidevalt ja püsivalt uuendada märksa odavam, kui kunagi tulevikus seda ühe korraga teha. 

Ehk kokkuvõtlikult - hoides oma veebiprojekti koguaeg uuendatuna on uute arenduste ja muudatuste tegemine oluliselt odavam ja kiirem. Lisandunud boonus on see, et pidevalt projekti uuendamine säästab sulle mõne aja pärast kogu projekti uuesti loomise vaeva.

## Kõik see võib tunduda keeruline

Tehnoloogiad muutuvad ja arenevad tänapäeval väga kiiresti. Kõige sellega sammu pidada on päris keeruline ja veel keerulisem on see inimestele, kes igapäevaselt selles maailmas ei tegutse.

Kui sa annad oma ettevõttes kellegile toote omaniku (tellija) rolli, võid sa sellega juba teha esimesi samme läbikukkumise suunas. Kõiki neid asju, mida ma kirjeldasin on suhteliselt lihtne juhatusele selgitada, kui sa oled neist teadlik. Tooteomanikud, kelle jaoks see ei ole põhitöö, ei suuda seda samas teha. Ja nii võib juhtuda, et sinu ettevõte ei saa kõike seda kasu, mida su arenduspartner sulle võiks pakkuda. Seepärast, kui sa soovid oma toodetest ja arenduspartneritest maksimumi ja parimat saada, [võta minuga ühendust](/contact) - või kellegi minu sarnasega.



How to choose your partner when you are not very tech-savvy? Here are some of the things you should consider when evaluating your potential partners and their quotes.

Kuidas valida endale arenduspartnerit, kui sa ei ole väga veebitehnoloogiatest teadlik?  Panin kirja mõned asjad mida silmas pidada ja kaaluda arenduspartnerite valikul.

Five things to consider when choosing a new IT development partner

Viis asja mida kaaluda uue IT partneri valikul

The (web) product development for a client often looked like this about 15-20 years ago (and still does relatively often):

- a client comes to the agency
- the client explains their requirements
- the agency presents a quote
- the client accepts the quote
- the agency starts developing what was requested
- during the development, the client presents additional requirements
- the project goes over the deadline
- the agency finally delivers the project (and often over the budget)

If startups delivered their products like this, they would often go bust before first investment. Here are some things any company can do to get better results from product development:

## 1. Understand what problem you are trying to solve with the development

What startups do is explore the problem before the actual development starts. Talk to potential customers to understand what pain needs to be solved. They try to figure out the most effective ways of solving those pain points for the customers and how many resources the product frees for the customers.

## What any company can learn from this

Explore the problem within the company. Try to figure out the root cause of the issues. You could use the "five why's" technique to get to the bottom of the problem, for example. Google it or [ask me about it](/contact/). Sometimes the best solution to fix the issue might not be new project development. I have different stories to share about this. You, however, might not see this while someone from the outside could. Because "We have always done it like this".

## 2. Test the potential solution before you launch into full-scale development

So by now, startups have assumptions that the team must test. Sometimes they start with developing their MVP product, sometimes not. I, while very technical, am a fan of low-tech solutions. I adore when startups manage to find low-tech ways to test their assumptions without building the MVP. In his book "The Lean Startup", Eric Reis talks about a team who tested their solution by talking to their potential customers. They tried what their product would do by doing everything manually.

## What any company can learn from this

Do you even need product development? For a while now, I've suggested to my friends that ask me about building websites that they should not have a custom website built immediately for their new business. Go with services like Voog instead. They make it simple to test if your business will take off or not.

Only spend money when you are making money, or know that you'll make money back. Do not jump into product development before testing if a new project can even solve your problem.

## 3. Understand what is the Minimum Viable Product (in your case)

Once it is clear what is necessary, the actual development starts. But before that, teams usually explore what the minimum, which solves the problem at hand, is. Different companies and groups have developed various workshops for this. One of the most well-known ones is Google design sprint.

During exercises like this team writes down the requirements in the form of user stories. Those stories can be expanded, tested, deleted, reworked - everything to understand what works the best. Sometimes designers are included to build prototypes of interfaces. Including designers helps everyone present to understand what works and what does not better.

![stories.webp](https://strapi.kesselmann.ee/uploads/stories_4811424412.webp)

The result of the workshop is the list of user stories that everybody understands.

## What any company can learn from this

Workshops like these not only help a team to understand better what works and what is necessary. They also generate documentation that is the basis of the quote. Most product agencies understand user stories, and price quotes based on those stories are comparable. One of the biggest problems agencies have is how the customer can compare our quote to our competitor's quote. This question comes up because each agency talks to the customer, ask their unique questions, and receives their responses.

This process isn't good for the customer because asking those questions agencies help the customer create an image of what will be delivered. The idea in customers head is never going to be what chosen agency will develop and will be the basis of future "I thought you'd do this too" questions.

Instead, invest some time (and money) into preparing user stories through some consultant or in-house product owner. The investment will pay back in several ways:

- It will serve as a roadmap. You can track your project progress by seeing how many of your user stories are complete.
- It will serve as a basis for user testing. Based on those stories, you can create your test cases to test if the complete stories.
- It will allow you to keep track of new things which will come up during the development. You can easily see which changes have been made to the original document and understand that all the changes and additions come with a cost in time and money.

## 4. Develop in phases

The distinction between a startup and a regular company is that the startups operate in an environment of significant uncertainty. For this reason, each assumption that the startup comes up with will be tested. Let's say they assume that developing feature X will increase their customer retention. They will then set goals for the feature. Goals are either met or missed, but the startup will learn something either way. But most likely, they will save time and money by not investing a lot into something that would not have worked.

## What any company can learn from this

Build an MVP. Do not order big project at once. Doing development in phases will help you get to know your development partner better. Most importantly, though, it will potentially save you a lot of money. Consider this, which is worse:

- Potentially finding out early on that your project will not bring you the success you wanted and be able to stop at any time or
- Developing for a long time only to find out you've wasted a lot of time and money at the end of a long project.

There are many other benefits for developing in phases:

- You can evaluate progress better
- You can catch potential problems sooner
- You can put a stop to a process but still have a usable product while you switch partners
- You can much better change and manage priorities during the process.

## 5. Pick the right technologies

One of the most important things for the startup is to pick the right technologies. I've met several companies that have come to regret their technical decisions that they made due to the influence of resources available.

The problems that come from picking potentially wrong technologies are numerous. Still, for the startup, the most important ones are that development is slow, difficult and that the additional resources ( developers ) are hard to come by or expensive.

## What any company can learn from this

Pick the agencies that work with technologies that are widely in use. Languages and tools with wide acceptance make it easy to find alternative partners. Due to wide acceptance, you can be safe that technologies have great support environments, and thus the development is faster and cheaper.

## 6. Invest in quality

What startups often do, is concentrate on development speed and neglect code quality tools and testing. This concentration on speed often happens because the developing team is not strong enough to stand up to pressure from business development. Developers often fail to explain that the increasing amount of refactoring, bugs and code smell starts negatively affecting the rate of new features released incredibly quickly. So when the business side starts asking, "why is this taking so long" it is due to neglecting essential things early on.

## What any company can learn from this

Accept that code quality is essential for the longevity of the project. You'll probably want more features developed later on if the project was successful. Neglecting code quality will hinder the development of new features. You also need to understand that much like spade gets rusted if it's left out in the rain - the code accumulates technical debt by not having underlying software updated.

So while you might enjoy the cheaper quote of a company that does no testing, you will thoroughly hate the fact that at some point, all the development costs a lot, and the number of bugs is unbearable.

## But wait, there's more.

There always is more knowledge that can benefit you. Unfortunately, one of the biggest hurdles that technical people face is communicating all this to their customers—some agencies are excellent at this kind of communication. Work with them. Trust them. If you are unsure which one to talk to - [talk to me first](/contact/).

Tavalise veebiarenduse projekti sammud nägid juba 15-20 aastat tagasi umbes sellised välja (ja paraku näevad tihti ka praegu):

- Klient tuleb agentuuri juurde
- Klient selgitab oma vajadused
- Agentuur pakub oma lahenduse
- Klient võtab pakkumise vastu
- Agentuur alustab tööga
- Töö käigus esitab Klient uusi nõudmisi. Mis tihti muudavad seda, kuidas varasemaid asju tegema peab.
- Projekt ei saa tähtajaks valmis
- Agentuur annab tööd üle ja läheb tihti eelarvega lõhki.

Kui startupid niimoodi asju ajavad on nad tihti pankrotis varsti peale esimest investeeringut. Olen seda ise näinud. Siin on mõned viisid, kuidas asju paremini teha.

## 1. Süvene sellesse, mis probleemi sa tegelikult lahendad oma arenduse tellimisega.

Kui startupid alustavad soovitatakse neil alati väga täpselt defineerida see probleem mida nad lahendavad - enne arenduse algust. Nad räägivad potentsiaalsete klientidega, et aru saada nende valukohti ja kuidas neid lahendada. Nad püüavad leida selleks kõige efektiivsemad viisid ja aru saada, kui palju raha ja resursse nende toote kasutamine kliendile säästab.

## Mida sellest õppida võiksid?

Uuri probleemi ettevõtte sees, Leia probleemi algpõhjus. Kasuta põhjuste tuvastamisel näiteks "Viie miksi" tehnikat. Guugelda seda (5 why's) või [küsi minu käest selle kohta](/contact). Tihti ei ole parim lahendus mitte uue toote arendus vaid hoopis midagi muud - näiteks protsessi muutus. Mul on selle koha pealt häid lugusid, mida jagada. Ettevõtte sisese inimesena võib nende probleemide ja lahenduste märkamine olla samas keeruline ("Sest kogu aeg on nii tehtud"). Seepärast ongi hea kaasata keegi väljastpoolt ettevõtet.

## 2. Testi potentsiaalset lahendust enne arendust. 

Oletame, et sul on nüüd leitud võimalik lahendus oma probleemile. Mõnikord on sellisel hetkel vaja alustada oma MVP ( Minimaalne sobiv/elujõuline projekt) arendamist. Aga mitte alati. Kuigi olen tehniline inimene, siis meeldib mulle leida probleemidele "low-tech", ehk mitte nii väga tehinilisi lahendusi. Mulle meeldib väga, kui startupid leiavad low-tech lahendusi oma idee testimiseks. Eric Reis räägib mõne sellise loo oma raamatus "The lean startup".  Üks lugu on sellest, kuidas tiim testis oma äriideed kõigepealt kõike käsitsi tehes.

## Mida sinu ettevõtte siit õppida võiks?

Kas päriselt on ka vaja uut toodet arendada? Juba mõnda aega olen oma äri alustavatel sõpradel soovitanud ettevõttele veebilehe arendamise asemel mõni veebi ehitamise teenus kasutusele võtta. Sellised teenused teevad oma äriidee rahvani viimise ja testimise lihtsaks.

Samuti võiksid ka sina raha kulutada vaid siis, kui see raha tagasi majja toob. Ära torma uut rakendust arendama vaatamata, kas mõni lahendus juba turul ei eksisteeri või kas lahendust ei ole võimalik muul viisil testida.

## 3. Tee selgeks, mida sinu vajaduste puhul tähendab Minimaalne sobiv/elujõuline toode.

Kui on selge mis probleemi sa lahendad ja mida sul vaja on algab päriselt arendustegevus. Aga enne seda süvenevad tiimid sellesse, mis on absoluutne miinimum, mis käesoleva probleemi lahendab. Erinevad ettevõtted ja messkonnad on selleks välja töötanud erinevaid metoodikaid. Üks rohkem tuntum on Google disaini sprint. 

Selliste harjutuste käigus kirjutab meeskond üles projekti funktsionaalsuse kirjeldades neid kasutajalugudena. Neid lugusid saab lahendada, testida, kustutada või ümber kirjutada - kõike selleks, et paremini aru saada, mis teile sobib. Mõnikord on seda tööd tegevates meeskondades kaastatud ka disainerid et prototüüpida kasutaliideseid. Disainerid aitavad paremini visualiseerida seda, mis toimib ja mis mitte.

![stories.webp](https://strapi.kesselmann.ee/uploads/stories_4811424412.webp)

Tulemuseks on nimekiri kasutajaludest, millest kõik ühtmoodi aru saavad.

## Mida sellest õppida?
Sellised töökojad ei aita ainult paremini aru saada, mida vaja on arendada vaid genereerivad ka dokumentatsiooni, mis võib olla projekti dokumentatsiooni alge või sisend hinnapakkumiste küsimiseks. Enamik arendusettevõtteid saab kasutajalugudest väga hästi aru ja oskab nende põhjal sulle anda hinnapakkumise, mis on võrreldav teiste sarnastega. Üks suurimaid probleeme, mis agentuuridel on, on see, et kuidas saab klient omavahel võrrelda hinnapakkumisi, mis ei ole tehtnud sama info pealt. See probleem tekib, sest tavaliselt teeb iga agentuur kliendiga läbi oma küsimuste protsessi ja genereerib selle pealt hinnapakkumise - mis tegelikult ei ole teise agentuuri omaga võrreldav.

Selline protsess ei ole hea ei kliendi ega agentuuri jaoks. Sest kõigi agentuuride esitatud küsimuste tulemusena tekib kliendil mingi pilt, mida ta saab. Tegelikkuses ei pruugi see nii aga olla, sest kliendi ettekujutus ei ole sama, mis agentuuri ettekujutus. Sellest tulevad probleemid, kus klient mingi hetk küsib või ütleb, et " Ma arvasin, et te selle ka teete ".

Seetõttu on parem investeering teha projektile korralik analüüs kas maja siseselt või kasutades välist konsultanti ja teha korralik kasutajalugusid sisaldav dokument. Selline investeering toob sulle kohe raha tagasi mitmel viisil:

- Sul on ees arenduse "roadmap". Sa saad selle abil kenasti jälgida, mis on töös ja mis veel ei ole. Saad paremini aru, kui palju projekti lõpuni veel on vaja teha.
- Sul on olemas ka nimekiri asjadest, mida testida. Kirja pandud kasutajalugude põhjal on väga lihtne arendajal teste kirjutada aga ka sinul testida ja proovida, kuidas süsteem töötab.
- Sul on viis, kuidas jälgida mõtteid või ideid, mis tekivad arenduse käigus. Kogu aeg on olemas ülevaade uutest vajadustest ja nendest, mis olid juba hinnapakkumises. 

## 4. Arenda faaside kaupa.
Erinevus alustava startupi ja tegutseva ettevõtte vahel on tihti selles, et startupi säilima jäämine ja edukus on märksa ebakindlamad. Seetõttu on startupil mõistlik iga üles kerkiv eeldus testida. Oletame, et nad eeldavad, et mingi arendus või muudatus annab neile rohkem käivet või pikendab kliendi "eluiga". Sellisel puhul võtab startup tihti selle oletuse endale testimiseks seades eesmärgi ja selle eelduse ära testida nii hästi, kui võimalik. Eesmärk kas täitub või ei aga ettevõte õpib sellest kinldasti alati. Igal juhul tähendab see ettevõtte jaoks seda, et nad säästsid aega või raha läbi selle, et nad ei arendanud midagi, mis ei oleks tööle hakanud.

## Mida ettevõtted sellest õppida võiks?
Ehita MVP. Ära alusta suurarendusega, kui seda vaja pole. Faaside kaupa arendamine aitab sul arenduspartnerit tundma õppida aga peamiselt säästab sulle aega ja raha. Mõtle, kumb oleks hullem:

- Varakult teada saada, et sinu projekt ei too sulle loodetud edu ning seetõttu varakult projektile lõpu tegemine. Või
- Suure projekti lõpuni arendamine saamaks teada, et kulutasid palju raha ja aega millegi peale, mis ei toimi.

Faaside kaupa arendamise juures on palju kasulikku:

- Sul on võimalik projekti progressi paremini hinnata
- Sa tuvastad probleeme kiiremini ja jõuad neile kiiremini reageerida
- Sul on võimalik vajaduse korral arenduspartnerit vahetada aga endiselt edasi minna toimiva projektiga
- Sul on võimalik kiiremini hallata ja muuta prioriteete arendusprotsessi käigus.

## 5. Vali õiged tehnoloogiad
Üks olulisemaid otsuseid startupi jaoks on valida õiged tehnoloogiad. Nii mõnigi startup on saanud hiljem oma tehnoloogilisi valikuid kahetsema.

Probleeme, mis tehnoloogiavalikust tekkida võivad on palju. Startupi jaoks on neist olulisemad see, et arendus on aeglane, keeruline või on vaja kaasata arendajaid, keda on turult keeruline leida.

## Mida siit õppida?
Vali agentuurid, kes kasutavad tehnoloogiaid, mis on laialdaselt kasutusel. Sellised keeled ja tööriistad teevad arenduse lihtsamaks ja kiiremaks aga teevad ka sulle vajadusel partneri vahetuse lihtsamaks. Kui tööriistad on laialdaselt kasutusel, siis võid kindel olla, et neil on hea tugi, mis teeb nende kasutamisel arenduse kiiremaks ja efektiivsemaks.

## 6. Investeeri kvaliteeti
Mida startupid tihti teevad on see, et nad püüavad arendada võimalikult kiiresti ja jätavad kasutamata koodi kvaliteedi tööriistad ja testimise. Miks see juhtub on tihti seepärast, et arendusmeeskonnal ei ole piisavalt kogemust vastu panna juhtkonna ja müügi poolt tulevale survele kiirelt turule jõuda ja turgu haarata. Mida arendajad ei räägi sellisel puhul on see, et kiirustamise tulemusel tekib järjest suurenev vajadus asju ringi kirjutada või vigu parandada. Lõpuks hakkab nende tööde tegemine väga oluliselt mõjutama seda, kui kiiresti jõuab ettevõte uusi featuure välja arendada. Kui äripool küsib, et "miks see nii kaua aega võtab", siis vastuseks on alati see, et koodi kvaliteeti ja selle hoidmiseks vajalikke metoodikaid eirati projekti alguses.

## Mida tellijad sellest õppima peaks
Aktsepteeri, et projekti koodi kvaliteet on projekti eluea vaatevinklist esmatähtis. Kui algne projekt oli edukas, siis on tõenäoliselt mingi hetk vaja juurde arendada uusi võimalusi. Projekti alguses koodi kvaliteedi ja tehnilise võla eiramine tähendab hiljem sedasi, et uued arendused on ajakulukamad. Täpselt nagu läheb labidas vihma käes rooste ja teeb kaevamise tüütumaks, hakkab ka kood koguma "tehnilist võlga".

Seega kui algne hinnapakkumine võib mõnel ettevõttel olla odavam võib see tähendada sinu jaoks seda, et tulevased arendused on keerulised ja projekt on täis vigu. 

## Kokkuvõtteks
Rohkem teadmisi on alati kasuks. Üks takistusi, mida tehnilised inimesed tihti kohtavad on ülalkirjeldatu kommunikeerimine oma klientidele. Mõned agentuurid on selles väga head. Tööta koos nendega. Usalda neid. Kui sa kahtled, millisega edasi minna, [siis räägi kõigepealt minuga](/contact).



Developing your in-house products and services like startups makes a lot of sense for several reasons. Save time and money by copying them.

Majasiseste toodete ja teenuste arendamine startuppidele sarnaselt on väga mõistlik mitmel põhjusel. Säästa aega ja raha kopeerides ja õppidest neilt.

6 ways how your company can benefit from developing your project like a startup

Kuus viisi kuidas sinu ettevõte võiks võita kui arendada sinu järgmist projekti, kui startuppi

At one point, I started to wonder why was it so? How come some clients walk away with a broad smile, and others leave with satisfaction or dissatisfaction?

I started with what any analytical thinker would do - prepare a list of questions and interview different people to see their ideas on the topic. After I had run my series of interviews, a pretty clear picture arose.

Since my interviewees were often developers and project managers, they often brought up that successful projects have a clear goal, they are interesting to develop and offer a wide array of challenges. Challenges and essential goals are critical for developers to ensure the work does not become boring and provides different ways to learn and grow.

But the most surprising thing that came up was that a great customer representative is crucial. This single thing was the common attribute of all successful projects - great, knowledgeable, professional product owner on the client-side.

## The knowledge gap of IT.

There are often gaps between the knowledge of service professionals and customers ordering the service. No person knows all the details that say construction experts know. Like purchasing paint from the store, even simple things often require that you consult with the clerk in the store.

It seems to me that this knowledge gap in IT is one of the biggest in the world. Compare it to visiting your doctor. The doctor owns crazy amounts of knowledge about the human body, and often, they spend significant portions of your visit explaining to you what and why you need to do. And doctors specialise - you have a disease and organ-specific doctors and general practitioners. When it comes to your health, then you usually know what you don't know.

Now back to IT. Most people are not aware of the intricacy of the different layers that work seamlessly together when you press a button on the keyboard. The signal is released on the keypress, interpreted in keyboard, passed on through the wire to the computer, analysed by the controller, passed on through the memory to the screen, and displayed on it. This last sentence does not even explain all the steps of how the letter you just typed arrives on the screen. It does not explain how many different programs developed by thousands of other people does the job there. For example, if you are interested in how displaying a website works, read [this article here](https://salmenzouari.medium.com/what-happens-when-you-type-a-url-in-your-browser-and-press-enter-fc56f387b5e7).

And back to why I talk about the knowledge gap. Much of the work that project managers and owners do in the agency is explaining to customers how things work. This process is prone to many translation errors because, in many cases, the project managers "translate" the technical information acquired from developers to the customers.

These translation errors are often one of the reasons why things go sour between customer and client. The existence of translation errors and other similar problems is why the client-side project manager/product owner makes things smoother for both parties. They know how agencies work and what to demand from the contractor. They also know what and how to explain to the management.

## How you can benefit from all this

After explaining things from an agency perspective, I'll explain how having an in-house product owner can benefit you. Usually, ordering a project development falls to an employee who is considered good with IT or has suitable seniority or possesses the most in-house knowledge about what is necessary. Problems start at presenting essential information for getting the agency's price quote, comparing the quotes, picking the right agency or right technologies. They happen because there is a gap of knowledge and information between the person ordering the service and the agency offering the service.

Having a fantastic in-house product owner or product consultant means that they:

- help you to figure out what is necessary.
- help you to create an information package for the agencies. This package will serve as the beginning of the product documentation.
- press agencies for comparable quotes.
- negotiate better prices.
- have enough experience to pick out the best development partners. manage the process to ensure quality.
- manage the process to ensure quality.
- manage the process to ensure the project is stopped quickly when something unnecessary is developed.
- ensure the best possible price/quality ratio.

My goal is to make sure no company wastes time and money on products that a new agency will completely rewrite in a few years. I want to make sure the customers get the best possible service and gain money from IT projects, not waste it. If you are thinking about having a new product developed, perhaps consider [talking to me first](/contact).

Ühel hetkel tabasin end mõtlemast, et miks see nii on? Miks on nii, et mõni klient lahkub sinu juurest naerul suuga teised aga on vaid rahul või pole üldse rahul?

Ma alustasin nagu iga analüütiline mõtleja ja panin kokku nimekirja küsimustest mida küsida erinevatelt inimestelt, et teada saada, mida nad arvavad. Peale portsu intervjuusid hakkas välja kooruma võrdlemisi selge pilt. 

Kuna mu intervjueeritavad olid projektijuhid, arendajad või muud inimesed teostaja poolel, siis nad tõid välja, et edukatel projektidel on selge eesmärk, neid on põnev arendada ja nende arendamine pakub programmeerijatele rea erinevaid väljakutseid. Väljakutsed ja eesmärgid on ju väga tähtsad kindlustamaks, et töö ei muutu ühekülgseks ja igavaks ning pakub võimalusi midagi uut õppida ja areneda.

Aga kõige põnevam leid oli see, et edukatel projektidel oli kliendi, ehk tellija, poolel alati keegi, kes oli selles töös väga hea. See üks asi, mis oli kõigi edukate projektide juures sama oli see, et kliendi poolel oli pädev, professionaalne toote omanik, kes omas ka tehnilist tausta.

## IT teadmiste lünk

Igal alal on tellija, ehk kliendi ja teenuse osutaja või teostaja vahel teadmiste lünk. Mitte ükski inimene ei saa teada kõiki detaile erinevatel elualadel. Isegi poest värvi ostul on tihti vaja konsulteerida kas müüja või muu kohaliku konsultandiga, et saada vajalik toode ja tulemus.

Mulle tundub, et see lünk on IT alal üks suuremaid ja petlikumaid. Näiteks arsti külastades me teame, et nende teadmine inimkeha toimimisest ületab meie oma. Seetõttu on tihti üks osa arsti külastusest arsti selgituste kuulamine mingi keha osa või haiguse kohta. Ja arstid tihti spetsialiseeruvad veel väga spetsiifilistele osadele inimkehast - või vaid analüüside tegemisele. Seetõttu oleme aktsepteerinud, et meie ja arstide teadmiste vahel on lünk.

Tagasi IT juurde. Enamik meist ei tea, kui palju erinevaid koos toimivaid kihte töötab lihtsalt sel hetkel, kui sa avad oma veebilehitseja ja hakkad midagi aadressiribale kirjutama. Nupu vajutuse peale läheb signaal liikvele klaviatuuris. See töötleb signaali ja saadab selle arvutisse. Arvuti töötleb selle samuti ja signaal liigub läbi erinevate juhtmete ja programmide, kuni märk ilmub aadressiribale. Kõik mis ma siia kirja panin ei räägi tegelikult pooltki sellest, kui palju kihte ja protsesse vahepeal tööd tegid. Selleks, et asjad nii sujuvalt töötaks on sajad tuhanded inimesed kümneid aastaid tööd teinud. Kui sind see jutt mõlema pani ja soovid rohkem teada, siis võid alustada näiteks [sellest artiklist](https://salmenzouari.medium.com/what-happens-when-you-type-a-url-in-your-browser-and-press-enter-fc56f387b5e7).

Miks ma seda kõike räägin on seepärast, et enamik tööst, mida teevad projektijuhid või analüütikud IT alal on kliendile rääkimine, kuidas asjad töötavad. Paraku on selles töös tihti vead sees, sest nagu ikka tõlkides, lähevad osad asjad, mida arendajad või tehnilisemad inimesed rääkisid, kaduma.

Need tõlkevead on pahatihti põhjuseks, miks suhted kliendi ja arendusettevõtte vahel halvaks lähevad. Sellised tõlkevead ja muud sarnased probleemid ongi põhjuseks, miks kliendi poolel olev tehniline inimene protsessi mõlema osapoole jaoks paremaks teeb. Sellised inimesed teavad, kuidas arendus ettevõtted töötavad ja millist infot nemad vajavad. Ja nad teavad ka seda, kuidas kõike tehnilist tellija juhtkonnale selgitada.

## Kuidas see sulle kasuks võiks olla

Enne kirjeldasin, kuidas asjad paistavad agentuuri vaatevinklist. Nüüd sellest, kuidas klient, või tööde tellija saab kasu sellest, kui nende poolel on majasisene ekspert või tooteomanik. 

Tihti langeb mingi toote või arenduse tellimine ettevõttes töötajale, keda peetaks IT osas heaks või on tal piisav majasisene kogemus selle kohta, mida on vaja teha või mis probleemi lahendada. Probleemid algavad juba sellest hetkest, kui on vaja arendusettevõttele informatsioon edasi anda, valida hinnapakkumiste vahel või otsustade õige tehnoloogia kasuks. See juhtub, seepärast, et teenust tellival inimesel lihtsalt ei ole piisavalt taustteadmisi, et teha õigeid otsuseid või valikuid.

Seetõttu annab majasisese tehnilise tooteomaniku omamine sulle  järgmist:

- Ta aitab sul välja mõelda, mida täpselt on vaja tellida
- Ta aitab sul kokku kirjutada üheselt arusaadava infopaki, mis on aluseks ka toote dokumentatsioonile
- Kuna algdokumentatsioon on detailne ja üheselt arusaadav saab ta ka hinnapakkumised, mis on tehtud sama sisendi pealt ja on seetõttu hästi võrreldavad.
- Ta aitab sul kaubelda paremat hinda või leida agentuuri, kes teistel viisidel saab pakkuda paremaid hindu.
- Tal on piisavalt teadmisi et valida parimad võimalikud koostööpartnerid ja hallata tellimuse protsessi.
- Tal on teadmised et küsida kvaliteeti ja jälgida kvaliteedi säilumine läbi projekti terve eluea.
- Ta haldab protsessi ja saab tõmmata pidurit kohe, kui arendusprotsess peaks kuidagigi kiiva kiskuma hakkama.
- Ta kindlustab sulle parima hinna/kvaliteedi/aja suhte.

Minu eesmärk ongi kindlustada, et ükski ettevõte ei raiska aega või raha toodete või arenduste peale, mis kas ei ole vajalikud või lähevad mõne aastaga ajaloo prügikasti. Ma kindlustan, et kliendid saavad oma raha eest parima võimaliku teenuse ja võidavad IT'st raha läbi protsesside parendamise, mitte ei kaota raha. Kui sa kaalud uue toote või teenuse arendamist, siis ehk kaalud [kõigepealt minuga rääkimist](/contact).

To get the best out of developers, you need an in-house person who knows the business, IT, and technologies.

Selleks, et saada parim teenus hea raha eest, on vaja, et sul oleks maja sees inimene, kes tunneb nii äri kui tehnoloogiaid.

Kui tahad, et su It projekt laabuks ja oleks edukaks, alusta projekti dokumentatsioonist

Viis asja mida kaaluda uue IT partneri valikul

Kuus viisi kuidas sinu ettevõte võiks võita kui arendada sinu järgmist projekti, kui startuppi

Miks on nii vähesed veebiarendused edukad?