Навіщо ІТ - фахівцям витрачати час на документацію - SEO Blog - все про пошукову оптимізацію та веб розробку українською.

Навіщо ІТ - фахівцям витрачати час на документацію

via Shutterstock .

[ Про автора: Наталія Нішта - професійний розробник , втілений в образі миловидної панянки . Вважає свою роботу захоплюючим хобі , роблячи акцент на командну гру: « Якщо ви мене запитаєте , що таке проект, - то я відповім вам , що це люди , які його роблять . Я переконана , що особистість завжди залишає свій відбиток у будь-яких речах , які створює » . ] Кожен раз , коли я чую фразу « нашому проекту стільки - то ( 4 , 5 , 7 ...) років » , хочеться запитати : « чи є у вас документація і в якому вона стані ? » . Як показує практика , найтиповіші ситуації такі :
- Документації немає. Або керівництву про це нічого не відомо.
- Документація є. Однак керівництво про неї також має туманне уявлення . Дуже часто така документація не відповідає дійсності , вона неповна, а місцями навіть брехлива .
- Документація є, але пізніше виявляється , що вона суто технічна . Хочете виділитися на співбесіді ? Запитайте , чи немає на проекті документів , що описують бізнес - процеси ( швидше за все , немає) , чи є в команді аналітик або проджект - менеджер . А якщо документація таки є, то хто займається її веденням . Навіщо і коли це потрібно Зрозуміло, можна робити записи для чого завгодно . Але чи варто витрачати на це дорогоцінний час ? А якщо стоїть , то в яких випадках ? Керуючись здоровим глуздом , я виділяю два найбільш важливих для розробника виду документації : - описи бізнес - процесів проекту ( Business Process Documentation ) - на моє глибоке переконання , найпотрібніші з усіх можливих. Критично важливі для розуміння « а що тут взагалі відбувається». - опису особливостей і тонкощів технічної реалізації ( Technical Documentation ) . Критично важливі для загальнодоступних API і проектів ; тут якість роботи визначає розмір майбутнього community проекту. Інформацію по внутрішньому коду варто фіксувати тільки в разі крайньої необхідності. Про це рекомендую почитати в книзі пана Роберта Мартіна «Чистий код " . Звичайно ж , існує маса інших видів документації ( наприклад , призначена для користувача ) , але це вже зовсім інша історія . Метою даної статті є висвітлити аспекти теми , важливі безпосередньо для розробника . Отже , в яких же випадках варто потрудитися і що повинно до цього мотивувати . 1 . Пишіть для себе . Навіть якщо на проекті задіяна мінімальна кількість людей і всі « і так знають» , що , і де як працює , і які процеси підлягають автоматизації - ніколи не буває зайвим залишити « пару рядків» про змінених чи нових бізнес - процесах . Тому що навіть якщо ніхто , крім вас , не буде працювати з цим продуктом , то через півроку ви самі вже будете іншими людьми. І займаючись написанням документації зараз , насправді ви пишете її для себе майбутнього. 2 . Для навчання інших людей. Пользу описів бізнес - процесів для новоприбулих співробітників важко переоцінити . Варто нагадати , що величезні талмуди ніхто не любить , тому якщо вам випала честь займатися священною справою підтримки документації , завжди пам'ятайте про людей , які будуть читати ваші записи . Інформація про проект повинна бути загальнодоступною для співробітників організації , а особливо для проектної команди. Якщо у когось з учасників виникнуть питання по предметної області , він не буде бігати за колегами , а зайде у відповідний розділ документації . Зрозуміло , інформація повинна бути добре структурована і не завдавати пекельного болю в спробах щось в ній знайти . 3 . Умовна заменяемость . Мабуть, це самий неочевидний і важкий для розуміння пункт , в рівній мірі потрібний компанії , проекту , команді і безпосередньо розробнику . Мірою усвідомлення цього механізму цілком можна вимірювати свій професіоналізм . Тому зупинимося на ньому докладно. Написання документації - це процес відчуження інтелектуальної власності учасників проектної команди. Якщо така людина покине проект , при цьому не зафіксувавши свої напрацювання , - фактично він віднесе з собою інтелектуальну власність компанії , і в цей момент нічого вже вдіяти не можна. Залишається тільки сподіватися , що керівництво дозволило цій людині цивілізовано покинути проект , і він зрідка зможе давати свої консультації , якщо буде розпорядженні достатній час і бажанням . У мене викликає щире здивування , чому за настільки очевидною важливості інтелектуальної власності керівництво дуже часто поняття не має , що написано в документації , якщо вона взагалі є. Небажання вникати в особливості функціонування проекту (і бізнесу в IT -галузі взагалі ) породжує відповідне ставлення з боку розробників . Створення інформаційної бази в даному випадку - лише мала частина тих процесів , якими слід би цікавитися керівникам . Якщо вище керівництво не виявляє інтересу ні до чого , крім продажів , то не варто очікувати цього від рядових співробітників. У результаті якщо в компанії добре організовані процеси відчуження інтелектуальної власності та поділу знань , то всі учасники проекту автоматично робляться « умовно замінними » . Чому це добре і чому до цього варто прагнути :
- Це непогано компенсує ризики компанії при виході учасників з проекту.
- Це корисно для команди , т.к. в разі відсутності колегу можна підмінити без збитку для проекту.
- Це добре для співробітника , т.к. значно полегшує передачу справ послідовникам .
- Це погано для « незамінного » співробітника , який боїться втратити своє місце. Насправді ми всі в тій чи іншій мірі боїмося втратити роботу. Але найбільше цього бояться низькокваліфіковані «фахівці» , для яких пошуки нового місця можуть бути досить проблематичні . Якщо достатньо розслабитися і дозволити собі бути « незамінним » , то це якість неодмінно в майбутньому стане тим якорем , який заважатиме в досягненні нових кар'єрних висот і може серйозно пошкодити професійної репутації. Справжні фахівці не бояться документування , але потрібно визнати , що й не особливо люблять займатися цією нудною , хоча і корисною роботою. Дуже хочу зробити акцент на « умовності » замінності . Тому що немає ніякої гарантії того , що людина , що буде взятий на заміну , буде настільки ж відповідальним і кваліфікованим - хороший керівник завжди розуміє це. Якщо пощастить . По крайней мере, я завжди щиро на це сподіваюся . Хто і коли цим займається документування технічної частини - цілком очевидно - займається той , хто ці технічні рішення створює . Якщо технічне рішення здається елементарно простим , зрозумілим і прозорим - зрозуміло, немає сенсу постачати його зайвими описами . Якщо ж не все так тривіально , а ви все одно покладаєтеся на свою супер -пам'ять , а ваші послідовники « і так розберуться , якщо не дурні » , - це цілком лежить на вашій совісті . Однак якщо системний архітектор або техлід настійно просить зробити « пару рядків » у вікі з технічної реалізації - варто його послухати , якщо не з почуття глибокої поваги , то хоча б з жалю. В силу своєї патологічної зайнятості навряд чи ця людина буде просити двічі , а в разі чого - голову зніматимуть саме йому. Описи бізнес - процесів дуже важливі з точки зору розвитку продукту , і ними зазвичай займаються аналітик ( BA | SA ) або проджект - менеджер ( PM ) . Все дуже просто - в нормі вони більше всіх знають про процеси всередині проекту , тому ніхто краще за них з цією роботою не впорається . Отже , ви вирішили змінити проект. Якщо він вже запущений , то варто поцікавитися : 1 . Наявністю документації та її специфікою (про що вона - технічна , користувальницький help , бізнес-процеси & amp ; so on ) ; 2 . Хто зайнятий у процесі підтримки? Якщо це самі програмісти - будете мати справу з технічною документацією. Якщо це аналітик або проджект - менеджер - може побут , вам пощастить з описом бізнес - логіки . Спеціальний технічний письменник і призначена для користувача документація - теж непогано : звідти , як правило , можна вивудити знання про логіку функціонування програми. Як би там не було , документацію пишуть люди , і вона багато в чому залежить від їх спеціальності . Якщо записів по бізнес - процесам немає , запитайте про можливість їх появи: вас повинні цікавити перспективи розвитку проекту . Ви повинні розуміти , що чим проект більший і давнє, тим складніше в ньому процеси , і без осудною документації ( бажано шаруватої або модульної ) дуже легко втратити контроль . А це завжди призводить до одного й того ж плачевного результату . Про масштаби і симптомах цієї катастрофи можна почитати все в тій же книзі Роберта Мартіна «Чистий код» . У новому проекті варто дізнатися , чи планується ведення документації , в якому вигляді , хто цим буде займатися. І взагалі , побільше довідатися про те , як ваша потенційна команда бачить собі майбутній процес розробки.

Якщо документації бізнес - процесів немає , а ви працюєте в старому проекті і не збираєтеся звідти йти , але є бажання виправити становище : як бути і що робити - про це я напишу в одній зі своїх наступних нотаток .

Опубліковано: 03/09/14 @ 06:32
Розділ Різне

SEO Блог

Навіщо ІТ - фахівцям витрачати час на документацію

Рекомендуємо: