30 сентября 2010 г.



Путь джедая - эпизод 5, Империя наносит ответный удар

Пришла пора продолжить рассказ. В предыдущем эпизоде я попал на новый проект разработчиком  и начал закрепляться в команде.

Давным давно, в далекой-далекой галактике... проект набирал ход, начали появляться новые направления разработки, заказчик понемногу втягивался в проект и наше понимание его бизнеса постепенно росло. Однако не все было спокойно. Периодически, заказчика бросало из стороны в сторону, что выливалось в частую смену приоритетов направлений работы. Кроме того, вот-вот должен был состоятся первый значительный релиз, с которым должны были начать работать бесчисленные дилеры нашего заказчика. В это время я активно занимался самообразованием и ждал момента, когда смогу продвинуться по служебной лестнице до какой-либо позиции, связанной с управлением. Можно сказать, управленческая сторона IT (не путать с темной стороной силы!) стала мне по-настоящему близкой и интересной.

Честно говоря, интерес к управленческой стороне IT тлел во мне уже очень давно. Причем «тлел» будет самым правильным словом для описания эволюции этого интереса. Довольно продолжительное время я не делал ничего, чтобы как-то спровоцировать его рост и подкрепить этот рост теоретическими и практическими знаниями. Мне было достаточно мысли, что я и так нахожусь на полу-руководящей позиции технического менеджера (до момента как я попал на текущий проект) и казалось, что совершенно незачем тратить на самоподготовку в этой области дополнительное время. Наверное, некоторое время я относился к управлению как очень многие руководители (особенно гос-предприятий и особенно в нашей стране), считающие что самой должности управленца достаточно для успешного управления.

Так было до тех пор, пока я не прочитал по совету своего начальника замечательную книгу: «Becoming A Master Manager: A Competency Framework» под редакцией нескольких авторов - Robert E. Quinn, Sue R. Faerman, Michael P. Thompson и Michael R McGrath. После ее прочтение мое отношение к управленческой науке сильно изменилось. И даже не из-за содержания данной конкретной книги. Это очень достойная работа и, возможно, я к ней еще вернусь, чтобы рассказать подробнее. Дело было в том, что я увидел и осознал, что управление это не просто должность и полномочия - это целая наука со своими секретами, приемами, уловками и подводными камнями.

И тут Остапа понесло - за полтора-два года я прочитал целую уйму книг и каждая из которых все больше и больше раскрывала для меня премудрости управления и провоцировала на поиск и чтение новых. Фредерик Брукс, Скотт Беркун, Эдвард Йордон, Ицхак Адизес, Джоэл Спольски, Стив МакКоннелл, Том ДеМарко, Элияху М. Голдратт - вот список самых основных и важных авторов, изученных за это время (ссылки в конце статьи). Считаю, что работы этих людей обязательно должны быть изучены IT менеджерами - пускай не полностью, хотя бы основные их части. Как минимум, они расширят кругозор, как максимум - помогут в повседневной (или будущей) работе руководителем.

Итак, если хотите чему-то научится - читайте. Читайте много, но избирательно. Не исключено, что время от времени вы натолкнетесь на что-нибудь не сильно интересное и полезное, но это мелочи по сравнению с приобретаемыми знаниями и их значением. Этот совет относится не только к управленцам, но и к разработчикам, которые хотели бы далее заниматься своим любимым делом и не занимать управленческих позиций. Тут тоже есть кого почитать: уже упоминавшиеся Стив МакКоннелл и Джоэл Спольски, Мартин Фаулер, Кент Бек, Гради Буч, Роберт Гласс, Банда Четырех. И это не вспоминая об авторах, пишущих на тему конкретных направлений разработки и технологий.

Однако, вернемся к проекту.

Как я писал выше, проект двигался вперед, появились новые направления разработки, работа кипела. Вот-вот должен был состоятся важный релиз. Но, как это бывает, его приходилось откладывать. Это происходило по многим причинам, но главная из них - частая смена требований и приоритетов работы. Особого опыта управления требованиями у нашей команды не было, как не было и опыта гибкой разработки (тут надо заметить, что главной проблемой при внедрении гибких методик стало бы убеждение и обучение заказчика этому методу работы).  О способах преодоления этой проблемы можно рассуждать довольно долго, поэтому я, пожалуй, оставлю ее для других публикаций. Сейчас же упомяну другом, довольно важном, но часто незаметным и пренебрегаемом компоненте разработки.

Этот компонент - инфраструктура проекта. Когда она в порядке и полностью поддерживает проект - она незаметна. Это как работа футбольного арбитра - признаком его хорошей работы на поле считают его незаметность для зрителя. К сожалению, осознание ее важности приходит тогда, когда ее не хватает. По крайней мере, у нас это случилось именно так - империя нанесла ответный удар. Мы познали если не все, то многие «прелести» в процессе поддержки приложения. И потеряли достаточно нервных клеток - уж ничуть не меньше, чем штурмовик на картинке слева :)

Пока работа над очередным модулем кипит, отсутствие хорошей инфраструктуры для сборок версий, дистрибутивов, обновлений не так заметно. Но когда работа завершена, релиз близко или уже состоялся, проявляются все недостатки и грабли отсутствия крепкой инфраструктуры. Банальные операции обновления и сборки делаются в полу-ручном режиме с большим шансом на ошибку, которые обязательно рано или поздно происходят. Естественно, требуя прорву времени на исправление. Причем занимая это время не самой интересной и полезной работой.

Вердикт? Обращайте внимание на инфраструктуру проекта заранее. Решите как будут делаться сборки и развертывание приложения на реальном окружении. После этого обязательно автоматизируйте эти процессы - это позволит избежать ошибок, связанных с человеческим фактором. Обращайте внимание и на структуру репозитария вашей системы контроля версий (вы ведь используете такую систему, правда?). Разработчикам должно быть легко и без лишнего напряжения извилин работать с репозитарием. И да, развертывание системы для разработчика тоже по возможности должно быть автоматическим. Пускай тратят свои интеллектуальные способности на решения задач разработки. Конечно же, это все советы общего характера. Но лишь потому, что все они требуют отдельной статьи.

Наш релиз в конце концов состоялся. С трудом, с работой ночью, но состоялся (если кто-то из команды, так или иначе работавших над проектом «Арарат», это читает - всем огромное спасибо!). Проект вышел на новый виток, новый этап своего развития. Поэтому, продолжение следует...


Справка

На данный момент (сентябрь, 2010) проект представляет собой комплекс приложений для крупной мебельной компании в Беларуси: ERP система, приложение для крупной дилерской сети, комплекс автоматизации производства. Каждое из них, в свою очередь, состоит из более мелких, но достаточно самостоятельных, модулей (управление сложным каталогом продукции по спецификации BMECat, графическое моделирование с трехмерным отображением, история изменений и синхронизация данных, модуль работы со сканерами штрих-кодов и печати этикеток и другие, более специфические). За основу был взят open-source проект JFire, хотя с течением времени от него остался только самый каркас. Архитектурно представляет собой клиент-серверное приложение: JBoss на стороне сервера и Eclipse RCP на стороне клиента. 


Полезные ссылки:




Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


Комментов: 0

Отправить комментарий