Я тут подумал, каналу скоро два года, а я так и не собрался представиться и рассказать о себе.
Исправляюсь.
#знакомство
Здравствуйте.
Меня зовут Борис Романов и сейчас я
Когда-то давно, еще в 90-х, я был программистом, сочинял программы на тему управления документами, всякие архивы, документообороты, формочки, поиски т.п. Писал на С++, мне очень нравилась выразительность этого языка. Но, надо признать, временами получалось достаточно громоздко.
Позднее, в 2000-х появился .NET и C#, код стал лаконичнее и выразительнее. Особенно, когда появились лямбды, LINQ и прочие функциональные приблуды.
Вообще, мне очень нравиться программировать. это прикольно и интересно. Я когда-то (надо же, уже 12 лет назад!) даже писал про это пост на хабре.
Процессы разработки были тогда еще дикие, неформализованные. Роли аналитиков, продактов просто не существовали. В команде был руководитель проекта, разработчики и (иногда) тестировщики. Про скрамы и водопады никто не слышал. Люди просто собирались и работали. Помню, когда появился трекер багов - bugzilla - так это было просто откровение :).
Постепенно выяснилось, что для того, чтобы создавать хорошие и полезные программы, уметь программировать мало. Большую и сложную программу, даже если и сумеешь осознать, в одно лицо не напишешь, помощники нужны. А когда народу больше одного, то, вот незадача, нужно как-то договариваться, координировать усилия и сводить результаты вместе.
Т.е. сначала нужно суметь нарезать еще не существующую (а может и существующую, но пока частично) большую программу на части так, чтобы можно было поделить работы по разработке.
Потом спланировать, кто, когда и как будет реализовывать эти части. А потом еще и отслеживать( и корректировать!) ход работ в процесс, ибо планирование - это хорошо, но реальность всегда преподносит сюрпризы.
Так что к началу второй декады 21 века я постепенно переквалифицировался из программиста в странный гибрид архитектора и менеджера. Читал книжки про UML и управление проектами, пытался осмыслить вероятностную природу рисков. Даже статью тогда написал про использование MS Project для управления проектами по разработке ПО.
Тогда я впервые стал задумываться, что перед разработкой неплохо бы сначала понять, а что же именно нужно запрограммировать. Позиция "давайте сразу нормальные требования, будет вам нормальная программа" очень удобна, но в реальной жизни работает плохо. В том смысле, что требования все равно приходят ненормальные и все равно многое приходится переделывать.
Так, в примерно в 2007-м году я с командой студентов взялся пилить новую версию нашей флагманской системы документооборота. И мы даже за полтора года сделали очень, на мой взгляд, пристойное решение. Но выяснилось, что несмотря на множество классных технических решений, система не применима в реальной жизни, так как в ней нет заметного количества небольших, но жизненно необходимых функций. А в команде молодых программистов, не погруженных глубоко в предметку документооборота, никто просто понятия про не имел о таких потребностях. И вот этот набор недостающих функций утоняли и доделывали еще года полтора.
—————————————————————————
😉если вам интересно, то продолжение последует...
