thekonst.net разделы   пропаганда :: автор :: программизм :: писанина :: резюме :: фото :: ::
 
[27.08.09] методологии или карьерное строительство в IT
[07.09.06] Россия-2006: Москва
[08.08.06] Испания-2006: немного об Андалузии
[07.08.06] Украина, июнь-2006: гламурно об эпиляции
[07.08.06] Украина, июнь-2006: бабушке - 81
  [29.06.06] Украина, июнь-2006: харьковская политика
[29.06.06] Украина, июнь-2006: об учреждениях
[29.06.06] Украина, июнь-2006: прибытие
[29.04.06] Хроника происшествий: катастрофа лайнера
[07.03.06] Остров Гран Канария: маленький континент
  [ подписка ]
[ архив .. ]
18 Oct 2002 :: Вот, отсканировал и выложил в галлерею фотографии из поездки в Брашов... [ дальше.. ]

22 Jan 2002 :: Наконец-то я смог себе позволить попасть домой сразу после работы. В последнее время количество всяческих вечеринок резко возросло, и я уже начал волноваться, что не успею вовремя (до конца января) закончить статью о демонах в UNIX для журнала argc & argv, которую пообещал дописать вовремя... [ дальше.. ]

31 May 2002 :: Думаю, все уже слышали, что недавно вышла новая версия 7.3 дистрибутива RedHat Linux. Так как образы дисков доступны для свободного скачивания с ftp производителя (а в Linux по-другому быть не может), уже на следующий день на работе сисадмин записал мне дистрибутив на болванки... [ дальше.. ]

[ 27th Aug 2009 ] методологии или карьерное строительство в IT | 9 комментариев | комментировать

На дворе - век высоких технологий и компьютеров. Неизвестно это только коматозникам, пребывающим в этом состоянии с 80тых годов прошлого века. Вполне естественно, что такая востребованная специальность как программирование также является и вполне доходным занятием. Зарплаты занятых в разработке софта специалистов в разы превышают доходы работников некоторых других сфер экономики. Девчонка в баре сразу смекнет, что если ты программист, то за душой у тебя какая-то наличность наверняка имеется и за пару «Маргарит» заплатить ты в состоянии. Именно поэтому информационные технологии привлекают толпы случайных и посредственных людей.

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

/Manager

Заветной мечтой наемного работника издавна было ничего не делать и получать за это деньги. Человечество знало всего две таких работы за свою историю: ростовщичество и проституция. Для первого нужны деньги, для второго – сиськи. Но что делать, если нет ни того ни другого? Приходится работать. Правда, не очень хочется. Поэтому многие горе-менеджеры в IT подчеркивают, что плевать они хотели на детали. Действительно, какой смысл в деталях, если ты в них все равно ничего не понимаешь? Самое главное теперь - это настроить Процесс, - говорят они. Как только процесс поставлен на правильные рельсы, ни требований, ни даже квалифицированных и ответственных исполнителей уже не нужно. Процесс сделает все сам. Код напишет, отладит, и даже задокументирует.

Поэтому, мой посредственный друг, если ты твердо решил идти в IT-менеджеры, при каждом удобном случае повторяй: "мне важно настроить Процесс". На вопрос в чем смысл твоей работы после того как процесс настроится, отвечай уклончиво.

Для того, чтобы тебе было чем подкрепить эту мантру, японские производители невычислительных машин с колесами придумали несколько интересных слов и обозначений. Это SCRUM, XP и Lean. Теперь менеджеру процесса разработки не нужно годами вырабатывать свой способ организации работы команды. Достаточно заставить компанию оплатить тренера, который за скромное вознаграждение сам объяснит все нюансы той или иной методологии начальству и команде. Тем самым ты поступишь по-христиански: дашь заработать еще одному человеку, у которого с программированием и руководством так же плохо, как и у тебя. Эти люди еще называются евангелистами, что только подчеркивает верность выбранного тобой пути.

Разработчикам тренер расскажет, что всю жизнь их учили делать то, что им говорят. Но теперь все будет иначе. Чтобы заработала методология, разработчикам предложат взглянуть на вещи по-новому и почувствовать себя не просто членами одно команды, но и самой командой. Напоминает коммунизм, где "все вокруг колхозное, все вокруг мое".

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

С этим историческим отступлением мы переходим к следующей главе, на случай, если тебе посчастливилось попасть разработчиком в команду с прогрессивной методологией. Я научу тебя, как и там быть на хорошем счету, неплохо зарабатывать и продвигаться по карьерной лестнице, совершенно при этом не работая.

/Developer

Если для Менеджера важен Процесс, то бездарный Разработчик тяготеет к Коммуникации. В команде, между командами и любой другой, которая способна сократить время, в которое он будет заниматься непосредственно разработкой. Так как именно этого он и не умеет. К тому же, написание кода - это огромный риск показать свою некомпетентность.

Благо, методологии поощряют Коммуникацию. Они называют это "силой команды", в которой нет ролей, но есть свобода сотрясать воздух днем и ночью. Созывать митинги, где можно часами обсуждать архиважные вещи вроде структуры каталогов проекта.

Краеугольным камнем любой такой методологии является команда. Только командная организация труда и коллективная ответственность могут позволить не заботиться о конечном результате. Также команда безлична. В ней все равны и окончательного слова ни за кем нет. Решить любую задачу в программировании можно массой различных способов, что открывает еще больший простор для обильных потоков нескончаемой коммуникации. Процесс, а значит и менеджер - его адепт, поощряют собрания и "налаживание коммуникации в команде". Чем ты и можешь заниматься постоянно, пока другие программируют. Теперь это ценное умение. Пускай коллеги-профессионалы угрюмо бычат свои мониторы. Тот факт, что они что-то напишут, еще ничего не значит. А если на глупые вопросы дилетанта они отвечают "пшел вон", то это еще и отличный повод указать на их плохую командную работу.

Результат работы, согласно методологии, - общее достижение всей команды, и твоей заслугой он будет являться в той же степени, как и того, кто работу действительно выполнил. Только тебе при этом удавалось еще и печься о коммуникации в команде, что дает право расчитывать на продвижение. Ведь Коммуникация - важная часть Процесса, что такой же посредственный менеджер оценит по достоинству.

/Стеб off

В большинстве случаев, итогом полугода разработки является весьма посредственный код, который один человек мог бы написать за неделю. Причина в том, что, заменив "бардак" на "процесс", вовлеченные в разработку люди не стали более ответственными или компетентными. Любой процесс не имеет никакого смысла, если его участники некомпетентны, а на результат им наплевать.

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

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

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

Самая простая модель с тим-лидером и разработчиками обеспечивает двухуровневую ответственность: за функциональность отдельных кусков отвечают индивидуально разработчики, а за общий продукт команды - тим-лидер. Формализовать описания заданий и контроль над их выполнением можно через самую простую систему учета заданий, ту же багзиллу. Трата времени по минимуму - тим-лидер описал задачу, разработчик выполнил. А если к этой модели подключить еще и тестера, ответственность получится тройной. Тестер проверит выполнение задания за разработчиком и, если найдет проблему, вернет на доработку. Стоит отметить один из главных недостатков такой модели. В ней негде затеряться бездарному разработчику. Слишком уж все прозрачно по части индивидуального вклада каждого, и результаты всегда очевидны.

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



дизайн и содержимое сайта © , 2001-2017 | ~ 5755 посещений в день | статистика