Показаны сообщения с ярлыком полезная статья. Показать все сообщения
Показаны сообщения с ярлыком полезная статья. Показать все сообщения

понедельник, 14 сентября 2009 г.

Негласные истины управления IT

В общем, имхо, автор копнул в правильном направлении...

Все дело в уважении

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

Саморегулирующееся поведение возникает в мире айтишников естественным образом, потому что он населен людьми с навыками креативного анализа и упорядоченной аргументации. Врачи — наиболее близкая к ним профессия. Пусть в медицине ставки выше, но в обеих сферах требуется профессиональная компетенция, которую нельзя симулировать, и профессионализм, который могут оценить лишь квалифицированные коллеги. Думаю, что все хорошие айтишники на планете поклоняются доктору Хаусу (за вычетом его пристрастий).

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

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

остальное

четверг, 30 июля 2009 г.

Читай код

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО - три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен. Однако, возникла некоторая загвоздка - CQG не являлось приложением баз данных, основанном на комбинации готовых сторонних технологий, таких как MS SQL сервер, Visual Basic, Delphi, JavaScript, и 1C - к которым я привык. Меня потряс объем приложения - почти 50 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.

Это был действительно серьезный и успешный программный комплекс, разрабатывавшийся десятками людей на тот момент на протяжении десяти лет, целиком написанный на С++, со своим собственным специализированным сервером БД, собственным встроенным языком программирования, собственным толстым клиентом, умеющим все, что может и не может пожелать трейдер, отказоустойчивый, работающий в реальном времени, сервера которого развернуты на ферме из сотен компьютеров и обслуживали порядка десятка тысяч пользователей одновременно.

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

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

Каких-либо иллюзий на свой счет, меж тем, к тому моменту у меня уже не осталось - я понял, что цена всем моим знаниям, университетскому образованию, и опыту - ломаный грош. Меня поражал простой факт - я был объективно образован в Computer Science гораздо лучше Тола, и _знал_ больше. При этом, и, после некоторого опыта работы, я был в этом абсолютно уверен - я бы не смог спроектировать и реализовать такую систему за год, как это десять лет назад с одним помощником сделал Тол. Сложность системы явно превосходила мои возможности - я бы по ходу работы закопался в деталях. И уж тем более, у меня не получилось сделать систему так гибко, чтобы она прожила 10 лет, и была до сих пор адекватна ситуации....

далее