Hoe't wy de kwaliteit fan dokumintaasje beoardielje

Hallo, Habr! Myn namme is Lesha, ik bin in systeemanalist foar ien fan 'e produktteams fan Alfa-Bank. No bin ik it ûntwikkeljen fan in nije online bank foar juridyske entiteiten en yndividuele ûndernimmers.

En as jo in analist binne, benammen yn sa'n kanaal, kinne jo net oeral komme sûnder dokumintaasje en nau wurk mei it. En dokumintaasje is iets dat altyd in protte fragen opropt. Wêrom is de webapplikaasje net beskreaun? Wêrom jout de spesifikaasje oan hoe't de tsjinst wurkje moat, mar it wurket hielendal net sa? Wêrom is it dat mar twa minsken, wêrfan ien it skreau, de spesifikaasje kin begripe?

Hoe't wy de kwaliteit fan dokumintaasje beoardielje

Dokumintaasje kin lykwols net negearre wurde om dúdlike redenen. En om ús libben makliker te meitsjen, hawwe wy besletten de kwaliteit fan dokumintaasje te evaluearjen. Hoe't wy dit krekt dien hawwe en hokker konklúzjes wy kamen, stiet ûnder de besuniging.

Dokumintaasje kwaliteit

Om "Nije ynternetbank" net ferskate tsientallen kearen yn 'e tekst te werheljen, sil ik NIB skriuwe. No hawwe wy mear as in tsiental teams dy't wurkje oan de ûntwikkeling fan NIB foar ûndernimmers en juridyske entiteiten. Boppedat makket elk fan har of syn eigen dokumintaasje foar in nije tsjinst of webapplikaasje fanôf it begjin, of makket feroarings oan 'e hjoeddeistige. Kin de dokumintaasje mei dizze oanpak yn prinsipe fan hege kwaliteit wêze?

En om de kwaliteit fan dokumintaasje te bepalen, hawwe wy trije haadkenmerken identifisearre.

  1. It moat folslein wêze. Dit klinkt nochal kaptein-like, mar it is wichtich om te notearjen. It moat alle eleminten fan 'e ymplementearre oplossing yn detail beskriuwe.
  2. It moat aktueel wêze. Dat is, oerienkomt mei de hjoeddeistige útfiering fan 'e oplossing sels.
  3. It moat begryplik wêze. Sadat de persoan dy't it brûkt krekt begrypt hoe't de oplossing wurdt útfierd.

Om gearfetsje - folsleine, aktuele en begryplike dokumintaasje.

Poll

Om de kwaliteit fan 'e dokumintaasje te beoardieljen, hawwe wy besletten dejingen te ynterviewjen dy't der direkt mei wurkje: NIB-analisten. Respondinten waarden frege om 10 útspraken te evaluearjen neffens it skema "Op in skaal fan 1 oant 5 (folslein net iens - folslein iens)."

De útspraken wjerspegelje de skaaimerken fan kwalitative dokumintaasje en de miening fan 'e enkête-opstellers oangeande NIB-dokuminten.

  1. De dokumintaasje foar de NIB-applikaasjes is aktueel en folslein yn oerienstimming mei har ymplemintaasje.
  2. De ymplemintaasje fan NIB-applikaasjes is folslein dokumintearre.
  3. Dokumintaasje foar NIB-applikaasjes is allinich nedich foar funksjonele stipe.
  4. Dokumintaasje foar NIB-applikaasjes is aktueel op it momint fan har yntsjinjen foar funksjonele stipe.
  5. NIB-applikaasje-ûntwikkelders brûke dokumintaasje om te begripen wat se moatte ymplementearje.
  6. D'r is genôch dokumintaasje foar de NIB-applikaasjes om te begripen hoe't se wurde ymplementearre.
  7. Ik bywurkje dokumintaasje oer NIB-projekten fuortendaliks as se finalisearre binne (troch myn team).
  8. NIB-applikaasje-ûntwikkelders besjen dokumintaasje.
  9. Ik haw in dúdlik begryp fan hoe't jo dokumintaasje kinne tariede foar NIB-projekten.
  10. Ik begryp wannear't ik dokumintaasje foar NIB-projekten skriuwe / bywurkje moat.

It is dúdlik dat it gewoan beäntwurdzjen fan "Fan 1 oant 5" miskien net de nedige details iepenbiere, sadat in persoan in reaksje op elk item koe litte.

Wy diene dit alles fia Corporate Slack - wy hawwe gewoan in útnoeging stjoerd oan systeemanalisten om in enkête yn te nimmen. Der wiene 15 analysts (9 út Moskou en 6 út Sint Petersburch). Nei it foltôgjen fan de enkête hawwe wy in gemiddelde skoare generearre foar elk fan 'e 10 útspraken, dy't wy dan standerdisearre.

Dit is wat der bard is.

Hoe't wy de kwaliteit fan dokumintaasje beoardielje

De enkête die bliken dat hoewol't analysts binne oanstriid om te leauwen dat de útfiering fan NIB applikaasjes is folslein dokumintearre, se jouwe gjin unambiguous oerienkomst (0.2). As spesifyk foarbyld wiisden se op dat in oantal databases en wachtrijen fan besteande oplossingen net troch dokumintaasje behannele waarden. De ûntwikkelder is by steat om te fertellen de analist dat net alles is dokumintearre. Mar it proefskrift dat ûntwikkelders dokumintaasje beoardielje, krige ek gjin ienriedige stipe (0.33). Dat is, it risiko fan ûnfolsleine beskriuwing fan útfierde oplossingen bliuwt.

Relevânsje is makliker - hoewol d'r wer gjin dúdlike oerienkomst is (0,13), binne analysten noch altyd oanstriid om de dokumintaasje relevant te beskôgjen. De opmerkings lieten ús begripe dat problemen mei relevânsje faker oan 'e foarkant binne as yn' e midden. Se hawwe ús lykwols neat skreaun oer backing.

As foar oft de analysts sels begripe wannear't it nedich is om te skriuwen en update dokumintaasje, de oerienkomst wie folle mear unifoarm (1,33), ynklusyf syn ûntwerp (1.07). Wat hjir as in oerlêst opmurken waard, wie it ûntbrekken fan unifoarme regels foar it byhâlden fan dokumintaasje. Dêrom, om de modus "Wa giet nei it bosk, wa krijt brânhout" net yn te skeakeljen, moatte se wurkje op basis fan foarbylden fan besteande dokumintaasje. Dêrom is in nuttige winsk om in standert te meitsjen foar dokumintbehear en sjabloanen te ûntwikkeljen foar har dielen.

Dokumintaasje foar NIB-applikaasjes is aktueel op it momint fan yntsjinjen foar funksjonele stipe (0.73). Dit is begryplik, om't ien fan 'e kritearia foar it yntsjinjen fan in projekt foar funksjonele stipe is aktuele dokumintaasje. It is ek genôch om de ymplemintaasje te begripen (0.67), hoewol't soms fragen bliuwe.

Mar wêr't de respondinten it (frij unanym) net mei iens wiene, wie dat dokumintaasje foar NIB-oanfragen yn prinsipe allinnich nedich is foar funksjonele stipe (-1.53). Analysten waarden meast neamd as konsuminten fan dokumintaasje. De rest fan it team (ûntwikkelders) - folle minder faak. Boppedat leauwe analysten dat ûntwikkelders gjin dokumintaasje brûke om te begripen wat se moatte útfiere, hoewol net unanym (-0.06). Dit wurdt trouwens ek ferwachte yn betingsten wêr't koadeûntwikkeling en dokumintaasje skriuwen parallel trochgean.

Wat is de ûnderste rigel en wêrom hawwe wy dizze nûmers nedich?

Om de kwaliteit fan dokuminten te ferbetterjen, hawwe wy besletten it folgjende te dwaan:

  1. Freegje de ûntwikkelder om skriftlike dokuminten te besjen.
  2. As it mooglik is, update dokumintaasje op in tiid, front earst.
  3. Meitsje en oannimme in standert foar it dokumintearjen fan NIB-projekten sadat elkenien fluch begrypt hokker systeemeleminten en hoe krekt beskreaun wurde moatte. No, ûntwikkelje passende sjabloanen.

Dit alles moat helpe om de kwaliteit fan dokuminten nei in nij nivo te ferheegjen.

Alteast dat hoopje ik.

Boarne: www.habr.com

Add a comment