Будущее Silverlight

Очень странно наблюдать поднявшуюся в последний месяц истерию по поводу того, что Microsoft якобы “разочаровался в WPF/Silverlight” и планирует смену курса в сторону набирающего популярность HTML5. Тема вовсю обсуждается на форумах MSDN, в комментариях серьезных блоггеров, на Хабре и даже в твиттере. Несмотря на явную невозможность нативной разработки под Windows при помощи ыHTML5/JS, у этой истерии, безусловно, есть корни. Осенью прошлого года официальные лица Microsoft уже обронили несколько фраз о переосмыслении стратегии развития Silverlight, а в начале июня подлили масла в огонь, показав Windows 8 с возможностью разработки на HTML5/JS и ни словом не обмолвившись о Silverlight. Если погуглить по фразе “Windows 8 silverlight”, то можно найти кучу криков о смерти Silverlight и плач тысяч разработчиков, которые выбрали Silverlight своей основной платформой для разработки и теперь считают себя брошенными на произвол судьбы. Добил фанов технологии .NET Community Manager Pete Brown, который высказался ясно и в то же время очень неопределенно:

“You all saw a very small technology demo of Windows 8, and a brief press release. We’re all being quiet right now because we can’t comment on this. It’s not because we don’t care, aren’t listening, have given up, or are agreeing or disagreeing with you on something. All I can say for now is to please wait until September. If we say more before then, that will be great, but there are no promises (and I’m not aware of any plans) to say more right now. I’m very sorry that there’s nothing else to share at the moment. I know that answer is terrible, but it’s all that we can say right now. Seriously.”

Сентябрь, о котором идет речь – это конференция Build, на которой ожидается релиз Silverlight 5, Windows Phone 7 Mango, а также первые настоящие презентации Windows 8 с объяснениями дальнейшей стратегии компании.

Безусловно, можно подождать еще 2.5 месяца и узнать, какую роль Microsoft отводит для Silverlight в своей новой концепции. Но ждать еще долго, а некоторые решения нужно принимать уже сейчас. Попробуем разобраться сами.

Итак, что у нас есть из не очень хорошего:

1. Microsoft, безусловно, немного разочарована скоростью распространения Silverlight и его положением на рынке. И хотя процент установки Silverlight в браузерах уже достаточно высок (на данный момент около 75%, http://www.riastats.com/), но он все равно еще недостаточен и не дает технологии стать по-настоящему популярной.
2. Другая проблема Silverlight – его неполная кроссплатформенность. Поддержка Windows и Mac – это, конечно, где-то 90-95% рынка десктопов (а, может, и больше, если верить http://gs.statcounter.com/#os-ww-monthly-201005-201105), но с точки зрения разработки широкопользовательских веб-приложений остается непокрытым весь Linux’овый зоопарк. Не добавляет очков и слабая поддержка SEO.
3. На мобильных платформах подержка Silverlight вообще стремится к нулю. Ни iOS, ни Blackberry, ни Android не поддерживают Silverlight и вряд ли будут стремиться к этому. Единственная платформа, где он поддерживается – это WP7, правда, не в браузере. Но доля WP7 на рынке мобильных устройств (http://itc.ua/news/gartner_android_yavlyaetsya_samoj_populyarnoj_os_dlya_smartfonov_53536) и количество заказов на разработку WP7 приложений пока настолько малы, что серьезно раздумывать о карьере разработчика мобильных приложений пока не получается.

В то же время несмотря на все эти недостатки Silverlight уже занял свою определенную нишу, где он очень силен, в первую очередь благодаря скорости разработки и возможностям, недоступным стандартному HTML/JS клиенту:

1. Enterprise и LOB RIA приложения (нивелируются проблемы слабой кроссплатформенности и распространенности)
2. веб-приложения, в которых пользователи готовы установить плагин ради получения доступа к продвинутым возможностям, а не уйти к конкурентам (не e-commerce)
3. мультимедиа-приложения с красивой и сложной анимацией, поддержкой video streaming
4. кроме того, Silverlight пока остается основной платформой для разработки под Windows Phone 7

С чем же связано то, что Microsoft, вложившая 4 года и миллионы долларов в разработку и продвижение кроссплатформенной .NET-технологии, потихоньку смотрит в сторону HTML5/JS? И что же все-таки будет с Silverlight дальше?

Во-первых, любой компании, которая производит ОС, важно привлекать как можно большее количество разработчиков на свою сторону. Silverlight и WPF требуют от не .NET-разработчиков изучения слишком многого. А возможность сделать пусть и простое, но все же приложение под Windows 8 на HTML5/JS – это шанс. Тем более, что Windows 8 позиционируется и как операционка для планшетов – а это очень перспективный рынок. Уверен на 99%, что в сентябре на Build будет сказано о полной поддержке WPF (а куда ж он денется?), а также Silverlight как минимум на уровне разработки таких же приложений, которые будут разрабатываться на HTML5/JS.

Во-вторых, есть ощущение, что Microsoft пойдет на еще один непопулярный, но очень важный с точки зрения развития своей мобильной платформы шаг – даст возможность разрабатывать нативные приложения на HTML5/JS в Windows Phone. Думаю, начиная с восьмой версии, чтобы поддержать версионирование, но, может, и в Mango (7.5) добавят. Криков о помощи будет еще больше, но Microsoft нужно догонять убегающие iOS и Android. Разработчики мобильных приложений под iOS и Android не торопятся переносить свои приложения под WP7 в том числе и потому, что это требует совсем других навыков. Если бы у Microsoft было хотя бы 40% рынка, они могли бы закрыть глаза на простоту разработки, но с текущими 6% им некуда деваться.

В-третьих, Silverlight никуда не уйдет из web’а в ближайшие 3-5 лет. Его доля будет по-прежнему неуклонно расти, приложения будут разрабатываться, но вот из своей ниши он вряд ли выйдет. Этому будет мешать развитие HTML5 и рост рынка веб-приложений под мобильные устройства. Конечно, Microsoft может попробовать разработать Silverlight-плагины для мобильных операционных систем и браузеров, но это огромные деньги, а эффекта практически не будет.

В поддержку Silverlight на нативном уровне верится еще меньше. Такое возможно лишь на Android, и то лишь благодаря Mono, который и сам находится в непонятном статусе. Еще возможно продвижение Silverlight на Symbian, благо с Nokia есть договор, но какой смысл? Ведь есть готовый WP7, который можно ставить на устройства. На фоне же прогнозов о росте использования мобильных веб-приложений и снижения нативной разработки (это банально намного проще и дешевле!) смысла вкладываться в эту сферу вообще нет.

Ну, и в-четвертых, отдельно стоит сказать пару слов о Silverlight vs. HTML5, вернее даже plugins (Flash/Silverlight) vs. HTML5 (это отдельная фишка: под угрозой HTML5 сейчас объединяются даже ранее враждовавшие разработчики Flash/Flex и Silverlight :)). На эту тему сломано уже очень много копий (почитайте отдельно, если вам интересно), но ясно одно: HTML5 не покрывает всех возможностей Silverlight и Flash/Flex, поэтому их рано списывать со счетов. Кроме того, как все правильно отмечают, плагины пополняются новой функциональностью быстрее, чем развивается HTML и обновляются версии браузеров. Если же отвечать на вопрос: что лучше использовать в качестве клиента в каждый конкретный момент времени, то советую почитать два отличных поста:

• http://www.hanselman.com/blog/ShouldIUseHTML5OrSilverlightOneMansOpinion.aspx
• http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2010/11/01/silverlight-versus-html5-really.aspx

Лично я себя намного комфортнее чувствую в разработке обычных ASP.NET MVC приложений, чем Silverlight, но это не значит, что нет приложений, для которых использование Silverlight будет более выгодным или дешевым. Особенно если мы говорим о портировании WPF-приложений в веб.

А вы что думаете по всему этому поводу?

Компании + вузы = исследования?

Только что прочел новость о том, что в ХНУРЭ открыли научно-учебную лабораторию по IT-технологиям. Особенно доставляет несколько моментов:

1. лабораторию открыли при непосредственном участии EPAM Systems
2. лабораторию называют “научно-учебной” :)
3. проректор по научной работе ХНУРЭ говорит (просто на камеру?), что открытие лаборатории позволит улучшить уровень исследовательской работы университета

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

Смешно другое. Каким боком это все к исследованиям и научной работе? Это ведь обычный компьютерный класс + программа обучения студентов, направленная на то, чтобы они знали востребованные на рынке языки программирования и технологии и их уровень адаптации на месте работы был минимальным. Аутсорсинговой компании, которая организовывает подобные курсы, не интересны исследования и научная работа. Об интересах студентов, компаний и вузов я писал 2.5 года назад, но все это до сих пор актуально.

Более того, уверен, что все в ХНУРЭ и других вузах понимают лучше меня, что лучшие студенты, которые уходят на подобные курсы, по сути, потеряны для исследований и научной работы. Их свободное время сначала будет уходить на курсы, потом они пойдут на практику в компанию, потом уйдут туда работать – и все. И произойдет это даже не на 5м курсе, а на 3-4м. Учеба (почти) закончится, диплом будет написан абы как, в аспирантуру студент не пойдет, потому что возможности там заработать нет.

Самое неприятное во всем этом – это то, что в данной ситуации ничего с этим поделать нельзя. Это как раз та модель, когда довольны остаются все стороны: студент получает высокоплачиваемую работу, компании – сотрудников, вуз – хм, в общем, он тоже не остается в накладе. Но это все краткосрочная перспектива. В долгосрочной перспективе студент не получает некоторые фундаментальные CS-знания и исследовательский опыт, предпочитая им изучение инструментов, вуз – талантливых студентов, способных заниматься наукой под руководством преподавателей и аспирантов, компании же не теряют почти ничего, их задачи такие “выпускники” покрывают, серьезных же R&D компаний в Украине нет или почти нет. Две “проигравшие” в долгосрочной перспективе стороны – студенты и вузы – либо не понимают этого (студенты), либо просто живут сегодняшним днем, предпочитая синицу в руке (вузы).

И ситуация не изменится пока в Украине не появится серьезный спрос на исследовательскую работу в области Computer Science и возможность платить за эти услуги. Только тогда вузы смогут удерживать у себя студентов хотя бы на период обучения, давая им другой, не промышленный опыт и знания, в рамках вузов начнут рождаться интересные разработки и стартапы, и курс нашей страны на IT рынке, возможно, сменится с аутсорсинга/аутстаффинга на разработку собственных продуктов и серьезные наукоёмкие исследования.

Прогноз развития рынка разработки ПО

Disclaimer. Ни один из “прогнозов” не претендует на оригинальность. Скорее это просто наблюдения и попытка их аппроксимировать на ближайшие 5 лет.

1. Плавный переход в веб

Десктоп-приложения ползут в веб уже давно и этот процесс , судя по всему, будет лишь продолжаться. Веб-приложения кроссплатформенны, проще в установке, обновлении и поддержке, доступны бОльшему количеству пользователей. Чем сильнее будут развиваться веб-технологии (браузеры, HTML, RIA-технологии), тем больше десктоп приложений будут менять прописку, и тем более солидными и функциональными они будут.

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

2. Браузер – единственное приложение или Терминалы наносят ответный удар

Наверно, самое часто используемое приложение на домашнем компьютере/лаптопе/нетбуке (нужное подчеркнуть) - браузер. Музыку можно слушать из инета, фильмы, информация, почта, офисные приложения, социальные сети и другие развлечения – тоже там. Google уловил эту тенденцию первым и уже предложил свое решение – Chrome OS. По сути, ОС с единственным пользовательским приложением – браузером. Сейчас эта идея выглядит немного утопично (ведь сколько еще приложений не в вебе!), но в перспективе 5-10 лет, думаю, мы увидим возрождение идеи терминалов в новой форме.

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

3. Развитие “облачных” технологий.

Благодаря своей специфике облака удобны для стартапов, интернет-приложений и сервисов с изменяющейся нагрузкой. В то же время и более консервативный корпоративный сектор все больше и больше движется в эту сторону. “Свои” приложения переводят в облако пока еще очень немногие, но покупать облачные сервисы стали все больше и больше. Это удобно – нет затрат на свою инфраструктуру, надежно, есть поддержка. Остаются лишь вопросы отказоустойчивости, безопасности данных и интеллектуальной собственности, но не для всех они актуальны.

Крупные продуктовые компании вовсю копают это направление. “Облачные” сервисы есть у Google (Gmail, Docs, etc.), Microsoft (Exchange, Office 365, Dynamics CRM, etc.), и многих других.

Кроме того, все больше и больше развиваются облачные платформы и для custom-решений. И это не только Amazon EC2, Google App Engine, Microsoft Azure. Очень много хостеров сейчас предлагают услуги облачного хостинга на своих платформах.

4. Значительное увеличение доли мобильных приложений

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

Но речь не о ПК и их будущем, а о росте количества мобильных устройств, а следовательно, количества приложений, а следовательно, объема этого рынка и возможности на нем заработать.

Чем более мощными будут становиться устройства и их операционные системы, тем более “крутые” приложения будут портироваться на них. Думаю, сейчас аутсорсинговым компаниям очень выгодно открывать отделы “мобильной разработки”, заказы есть уже сейчас, и их количество обещает только расти. Про продуктовые компании и говорить нечего.

5. Смещение акцента в разработке мобильных приложений с native в web

Идея проста. Мобильных платформ все больше, доля на рынке так или иначе будет отъедаться даже у текущих лидеров: Apple OS и Android. Если вы хотите, чтобы ваше приложение было доступно не 30% “мобильных” пользователей, а хотя бы 60%, то извольте создать версию своего продукта и под другие платформы. А это очень недешево, технологии и языки программирования везде абсолютно разные, следовательно, создавать новое приложение нужно почти с нуля. А потом еще и поддерживать их все. С веб-приложениями проще – реализация на сервере одна, подстраиваемся под размер экрана и, возможно, меняем немного внешний вид – и готово. С обновлениями тоже все просто. Дешево и сердито. Из плюсов также возможности продажи по подписке, показа рекламы – все это дополнительный заработок.

Понятно, что не все native приложения можно перенести в веб. Приложения, которым требуется высокая производительность или по-настоящему интерактивный и “богатый” интерфейс, еще долгое время будут создаваться только как native-приложения. В то же время с приходом HTML5 возможности веб-приложений еще больше увеличились.

Понятно также, что не все производители приложений вообще стремятся перейти на другую мобильную платформу. Но уже сейчас на рынке есть 2 крупных игрока, хотя бы под них многие будут стараться писать. А ведь еще несколько (RIM, WP7) отдадут все силы, чтобы вмешаться в дележ этого некислого пирога.

6. Уменьшение доли custom решений за счет создания более универсальных продуктов

Сразу оговорюсь, что речь только о корпоративном (или государственном) секторе. Пользователи не заказывают разработку продуктов на заказ.

Сложно говорить о каких-то цифрах, их у меня нет. Но, думаю, многие согласятся, что если раньше в разных сферах было много custom решений, призванных решить конкретные нужды конкретного бизнеса или предприятия, то со временем появились универсальные продукты, решающие нужды целого класса таких бизнесов. Примеры: бухгалтерия, CRM, ERP системы, системы обслуживания банков, CMS-ки, eCommerce-платформы, портальные решения (привет, Sharepoint) и т.д.

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

7. Робототехника и интеллектуальные системы

Можно сказать, эта сфера лежит за пределами широкого рынка разработки ПО. Ею занимаются университеты, исследовательские центры, и инновационные компании. Такие проекты практически невозможно встретить в “дикой” природе, в них есть интеллектуальная собственность (IP), отдельные алгоритмы и модули часто патентуются.

Однако, чем дальше, тем больше это направление будет развиваться. Правда, будет ли это происходить в Украине – большой вопрос. Зависит от нас с вами.

А что Вы думаете по этому поводу?

Взвешенный подход к Agile

В последний время все чаще попадается на глаза критика Agile и Scrum, а, точнее сказать, agile-евангелистов и подхода подготовки Скрам Мастеров. Сейчас это неплохой бизнес. Надо сказать, когда я впервые столкнулся с тем, как проводится сертификация на Скрам Мастера, у меня у самого волосы встали дыбом. Несколько дней тренинга, простенький экзамен, который может сдать практически кто угодно – и ты Скрам Мастер! Да, потом нужно участвовать в комьюнити, чтобы двигаться дальше, но в целом все это выглядит следующим образом:

- Я уже могу вести Скрам-проекты, учитель?
- Так точно, маленький падаван. Ты же прошел обучение и заплатил деньги сдал экзамен.

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

Также мне всегда было непонятно, почему тот же Scrum часто огульно описывается как панацея от всех бед, хотя совершенно ясно, что он подходит не для ВСЕХ проектов, и не для ВСЕХ команд. Как и waterfall, как и TDD, как и что угодно, серебряной пули же нет. В некоторых случаях Scrum просто менее эффективен, чем другие методологии, а иногда совершенно не подходит.

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

Сначала появилась статья, в которой хорошо описывались основные проблемы и давалась краткая выжимка фактов с предложением “быть честными”: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php (русский перевод здесь: http://experience.openquality.ru/agile-ruined-my-life/)

“Люди думают, что можно взять увечный проект, который уже не жилец, добавить немного Agile и заявить, как это было круто. Да ладно, ребята, никого так провести не удастся. Все точно знают, что это пропаганда. Хуже того, вовлеченные эксперты оказываются последними, кто узнает о тщетности таких действий на публику. На своем опыте они «обучаются» неправильным вещам и «делятся» своим знанием с новыми командами, продолжая дерьмовый цикл.”

“Одна из первых истин, которой учат в Scrum-классах: Scrum – не волшебная пуля. Оставшуюся часть времени вам говорят, что это лучшее изобретение человечества после нарезного хлеба. Все мы встречались и работали с парнями, у которых всегда есть ответ на любой вопрос – нужно только спросить. Решения уже приняты для любой задачи, которая у вас может быть. Такие люди чрезвычайно раздражают. Все равно что говорить со стеной. Плохо, плохо.”

“Работает ли Agile для распределенных команд? Смотря по обстоятельствам. Можно ли использовать двухнедельные отметки для оценки проектов? Смотря по обстоятельствам. Работает ли Agile в проектах по разработке встроенного ПО? Смотря по обстоятельствам. Черт! Всё зависит от обстоятельств. Порой как бы сильно я ни пытался быть вежливым, честным и открытым, я становлюсь похожим на тех ребят из Матрицы, когда вы смотрели ее первый раз. Они говорят много, но на самом деле это мало что значит. Звучит напыщенно, но по сути чепуха. Ненавижу давать такие советы. Знаю ребят, которые ненавидят их слушать.”

Были и другие статьи, все перечислять не имеет смысла. Но написать эту заметку меня натолкнул Боб Мартин, написавший статью “What Killed Waterfall Could Kill Agile”, в которой высветил проблему элитарности, присутствовавшей в водопадной разработке и проявляющейся, как он считает, в Scrum. Конечно, Боб выгораживает XP и наезжает на Scrum, но его слова не лишены смысла:

“The elitism engendered by Waterfall was being attacked. Neither Scrum nor XP had any role for an elitist who assumed authority without taking responsibility. In Scrum, the rule of the team is stronger than the rule of an Architect or Designer. Contributions are welcome, but not necessarily followed.”

“I didn’t think thousands of people would be lining up to get their certifications. But I had not considered the lure of elitism. It didn’t occur to me that this special training course, coupled to the term Certified Scrum Master, would become a wedge to break the alignment between authority and responsibility.”

“Indeed, the role of Scrum Master is considered so important, that it requires certification to obtain. If your Scrum team does not have a Certified Scrum Master, then something must be wrong with you.”

“The elitism is back, and it’s growing. More courses with certifications are available, and even more are envisioned. Other training companies are offering their own certifications. After all, the lure of elitism is a great moneymaker. The snowball is rolling down the mountain, and getting bigger with each turn.”

Agile – это хорошо. XP, Scrum, Kanban, Lean содержат множество прекрасных практик и подходов, как технических, так и организационных, которые помогают создавать отличные продукты, справляться с сложностью, изменениями. Но нужно действительно быть честными и не превращать его в бизнес.

Ошибки технических менеджеров проектов

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

Об общих ошибках управления проектами написано уже очень много, поэтому я не хотел бы повторяться. Об этом можно почитать здесь, здесь, а также в куче других мест - достаточно лишь погуглить по ключевым словам. Я же хотел бы остановиться на некоторых ошибках, которые свойственны именно бывшим техническим лидам, ставшим менеджерами проектов или начинающим выполнять эту роль в дополнение ко своим текущим обязанностям. Причем говорить я буду о бывших программистах, а не о QA, BA или ком-то другом, потому что:

• я на практике сталкивался в основном с PM, которые в прошлом были программистами, а не QA или BA - банально нет подобного опыта, поэтому мало о чем могу сказать
• на мой взгляд, PM из бывших QA и BA не будут совершать часть из перечисленных ниже ошибок, просто по тому что они специфичны для программистов
• я сам - программист, поэтому мне проще основываться еще и на своем личном опыте и своих ошибках :)

Думаю, любой человек, работая под началом разных менеджеров, видел различия в отношении и подходах. У каждого PM свой уровень знания и умений, менталитет, психология, поэтому стили управления отличаются. Но если посмотреть на PM, которые в прошлом были программистами, можно заметить некоторые общие черты и типичные ошибки, которые те совершают. Основная причина этих "типичных" ошибок - менталитет, установленные подходы и шаблоны работы в бывшей роли программиста, а не просто недостаток знаний или понимания процесса управления проектами. Почти любой программист, при условии хороших технических знаний и наличии лидерских качеств, может стать хорошим лидером, но это еще не значит, что он может стать хорошим менеджером. Между "управлением" продуктом, которым, по сути, занимаются DL или TL, и управлением проектом и командой, которым занимается PM есть большая разница.

Ошибка №1. Непонимание целей и задач роли PM

Я уже упоминал, что цели и задачи ролей DL и PM отличаются. Основная задача DL - реализовать продукт технически. Это его сфера ответственности. Основная задача PM - успешно завершить проект в рамках запланированных сроков, бюджета, объема функционала и его качества, таким образом сделав клиента довольным и счастливым. Попутно можно сказать, что основная задача QAL состоит в том, чтобы удостовериться, что полученный в результате выполнения проекта продукт - это именно то, что нужно клиенту и что качество этого продукта соответствует предъявленным требованиям, но QA мы пока что трогать не будем. Таким образом, обязанности PM состоят не только в том, чтобы общаться с клиентом, давать всем подзатыльники, а также писать спецификации и отчеты (изверги, бумажной работы навалили, ужас!), а в том, чтобы создать условия и наладить процесс работы, в рамках которых команда достигнет результата, попутно эффективно управляя требованиями, рисками, различного рода ресурсами (в том числе и человеческими) и т.д. И это все нужно понимать и делать, даже если PM - всего лишь дополнительная роль, которую вам приходится выполнять по долгу службы, а не настоящая должность.

Ошибка №2. Неумение смотреть на проект и продукт с точки зрения клиента (бизнеса)

Менеджер проекта в какой-то степени является промежуточным звеном между командой и клиентом. Поэтому если программист и DL могут позволить себе думать только о реализации и проблемах, связанных с ними, быть "по эту сторону баррикад", то PM уже должен думать не только о команде, но еще и о клиенте, его целях, желаниях и проблемах. Любой продукт, разрабатываемый в рамках проекта, несет для клиента какую-то выгоду (не обязательно финансовую). Если же мы в угоду желания попробовать новую технологию, реализовать эту фичу "по-своему" или даже просто по глупости убиваем эту выгоду - клиент не будет доволен. И PM иногда является единственным носителем полной информации о целях и желаниях клиента. Да, в какой-то степени это еще и обязанность QA, но зачастую они не могут принять решение в момент разработки, а лишь тогда, когда что-то уже сделано. Поэтому лишь PM может вовремя остановить разработку и направить ее в правильное русло. Нужно помнить, что PM является не только адвокатом команды перед клиентом, но и адвокатом клиента перед командой.

Ошибка №3. Считать себя самым умным и самым главным

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

Ошибка №4. Злоупотребление делегированием-исполнением, а не делегированием-руководством (микроменеджментом)

Любой менеджер должен уметь распределять задачи (делегировать их). Существует два основных типа делегирования: делегирование-исполнение и делегирование-руководство. Делегирование-исполнение выглядит следующим образом: "Возьми пилу, пойди в сад, спили все сухие деревья, а когда закончишь - вернись и доложи мне". То есть фокус идет на методах исполнения обязанностей, на том, как что-то сделать. Делегирование-руководство в таком случае может выглядеть следующим образом: "Очисти сад от сухих деревьев". То есть фокус идет на результат, которого нужно достичь, на то, что нужно сделать, а не то, как. Как очистить сад от сухих деревьев - спилить, срубить или спалить - исполнитель может принять решение и сам. Право выбора, равно как и ответственность за результат, возлагается на исполнителя. Чем делегирование-руководство лучше - оно дает возможность человеку проявить свои способности и творчество в полной мере, возможно, быстрее или эффективнее добившись результата. Но в то же время если человек еще не умеет принимать решения (допустим, он еще неопытен), то нужно это делать за него, но только после того, как он хотя бы подумает над своим вариантом решения - чтобы он учился.

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

Ошибка №5. Боязнь показать свое незнание

У программистов это чувство развито очень сильно :) Поэтому довольно часто менеджеру сложно спросить какие-то детали, попросить о помощи - ведь он вроде бы как самый главный в команде (см. ошибку №3), негоже перед подчиненными показывать свою слабость, вдруг перестанут уважать. Достаточно глупо и, к сожалению, иногда весьма критично для проекта. У PM есть куча других обязанностей, поэтому ему часто некогда вникать в детали, новые технологии и подходы разработки. Немудрено, что некоторые люди на проекте, которых вы раньше учили сами, вдруг окажутся осведомлены в чем-то техническом больше вас. Это нормально, не обращайте на это внимания, развивайтесь в свою сторону, и старайтесь наоборот стимулировать профессиональный рост своей команды, ведь чем сильнее команда - тем успешнее будет ваш проект.

Ошибка №6. Поверхностное отношение к команде и ее интересам

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

Ошибка №7. Остановка технического роста

Казалось бы, какое отношение это имеет к управлению проектом? Никакого. Но зато это имеет самое прямое отношение к реалиям жизни. Если бывший программист, став PM, полностью останавливает свой технический рост по принципу "я уже и так достиг всего чего мог в техническом плане, могу забить", то это, по сути, рубание ветки, на которой сидишь. Да, технические навыки не обязательны для того, чтобы быть эффективным менеджером, но тем не менее кто вам даст гарантию, что один из ваших следующих проектов, который будет через год или два, не потребует от вас занятия должности PL, который будет руководить и технической, и организационной частью проекта? Или что на вашем следующем месте работы это не будет обязательным требованием? А будете ли вы тогда достаточно подкованы в новых технологиях или подходах для того, чтобы довести подобный проект до успешного завершения? На мой взгляд, если уж вам так повезло, и вы прошли весь путь от падавана до мастера Йоды в программировании, то не забрасывайте свои технические знания в темный чулан, развивайте их, хотя бы на поверхностном уровне изучайте новые технологии и подходы к разработке ПО, совершенствуйтесь!

Успехов вам и вашим проектам!

Должен ли PM быть техническим специалистом?

Я уже не первый раз сталкиваюсь с вопросом, должен ли PM быть технически подкованным человеком или нет. Иными словами, должен ли у него быть опыт работы программистом или QA, для того, чтобы успешно вести проекты, связанные с разработкой ПО. И собственно, вопрос здесь даже не в том, возможно это или нет - опыт показывает, что есть нетехнические PM, которые с разной степенью успешности ведут проекты. Но в то же время тот же опыт показывает, что а) таких людей довольно мало, б) им иногда бывает сложнее, в) общественное мнение в лице различных IT-специалистов иногда отрицает эффективность такого PM. Столкнувшись с этим вопросом, я решил провести небольшой опрос среди моих друзей и сотрудников (бывших и нынешних). Выборка была порядка 20 человек (знаю, нерепрезентативная, но я и не старался делать соцопрос, скорее, получить дополнительную пищу для размышлений), люди абсолютно разного уровня и позиций: программисты, QA, BA, девлиды/тимлиды различного плана, и несколько ребят, которые так или иначе выполняют функции PM на своих проектах или ими являются. Задавал я, как правило, один и тот же вопрос, в краткой форме приведенный в заголовке данной заметки, а потом, по ходу дела, спрашивал детальнее, уточнял подробности, иногда дискутировал :) Ответы были разными, некоторые совпадали с моим мнением, некоторые - нет. Но в любом случае, я благодарен всем, кто согласился ответить на эти вопросы, в независимости от точки зрения, т.к. вы помогли мне увидеть бОльшую картину, чем была у меня в голове до опроса. Все-таки опыт у разных людей разный, поэтому одна голова - хорошо, а двадцать лучше. Также я немного потерроризировал гугл, а также сайты вроде www.stackoverflow.com, www.rsdn.ru и прочие уважаемые ресурсы.

Если очень коротко, то результаты опроса были следующими: где-то 40% людей так или иначе высказывались в пользу идеи, что у PM должен быть технический опыт, и что технический PM лучше нетехнического, причем неоднократно подчеркивались 2 мысли: лучший PM - PM-бывший программист, и лучший PM - PM-бывший QA. Я думаю, не стоит уточнять, у кого какое мнение ;) Остальные говорили, что либо технический опыт не имеет никакого значения, а иногда даже мешает, либо нетехнический PM способен эффективно руководить проектом, но все же не любым. Я же хотел бы высказать свои мысли по этому поводу, в том числе навеянные и общением на эту тему.

Чем занимается менеджер проекта

Менеджер проекта обычно отвечает за то, что проект будет выполняет в срок, в рамках выделенного бюджета, что результатом проекта будет продукт, который является тем, что хотел заказчик, и что продукт этот будет надлежащего качества. При этом в принципе, не особо важно, является ли продукт заказным или нет, кто заказчик - твой начальник, пользователи продукта или дядя за океаном, а также какие методологии/подходы/технологии были выбраны для реализации продукта. Это все варьируется, но цели - качественный продукт, удовлетворенный "клиент" и финансовая рентабельность разработки - остаются.

Для достижения этих целей, менеджер проекта занимается самыми различными активностями:

• планирование работ (или хотя бы помощь в этом в случае хорошей самоорганизации)
• распределение задач и отслеживание их выполнения (или хотя бы помощь в этом в случае хорошей самоорганизации)
• налаживание и управление различными процессами
• управление рисками
• управление командой (начиная от ее создания и заканчивая разрешением конфликтов)
• налаживание коммуникаций (с "клиентом", внутри команды)
• создание эффективно работающей команды, мотивация ее членов
• создание среды для эффективной и плодотворной работы всех остальных членов команды
• и т.д.

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

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

Чем отличается должность от роли на проекте

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

PM, менеджер проекта - это как должность/позиция, так и роль, и это часто сбивает людей с толку. Еще более сбивает с толку наличие кучи других лидерских позиций: Project Lead, Team Lead, Tech Lead, Dev Lead, QA Lead, Software Architect, можете продолжить сами. Я тоже раньше не мог точно сказать, кто за что отвечает, чем отличается, и вообще, кто все эти люди и что они здесь делают. Связано это с тем, что в разных компаниях и даже на разных проектах люди на этих позициях выполняют зачастую различные обязанности, а единого реестра как бы и нет... Расскажу, как я это понимаю, а вы если что поправляйте. Проще всего разобраться с Dev Lead и QA Lead - это явно выраженные технические позиции, которые четко совпадают с соответствующими ролями: они отвечают за техническую сторону реализации проекта, то есть разработку и проверку качества продукта. Программируют и тестируют они при этом или нет - не так важно, хотя чаще всего да. Позиции Tech Lead и Team Lead более размыты, человек на этих позициях может выполнять как чистую роль Dev Lead, так и несколько ролей: DL, QAL, иногда также PM, SA, BA. К тому же должность Team Lead может относится и к совсем другим сферам деятельности, по сути, это просто руководитель команды: системных администраторов, технических писателей, дизайнеров, бизнес-аналитиков и т.д.

Позиции Project Lead и Project Manager - самые интересные в этом списке, так как человек на каждой из этих позиций может выполнять кучу ролей: PM, DL, QAL, BA, SA, и др., в зависимости от проекта, и того, что понимается под этой позицией в отдельно взятом государстве, в данной конкретной компании, на конкретном проекте и т.д. Но все же разница здесь тоже присутствует. Обычно PL все-таки является техническим товарищем, объединяющим в себя как управляюще-аналитические роли (PM, BA), так и технические (DL, SA, иногда QAL), а вот PM'ами называют зачастую либо людей, играющих только роль PM, либо роли PM и BA, хотя в общем и целом это тоже далеко не гарантия.

Факторы, влияющие на то, может ли PM быть "нетехническим"

Таким образом, активности роли PM очень слабо связаны с техническими умениями. Но означает ли это, что можно взять классного нетехнического PM, поставить его на проект и тот приведет его к успеху? Нет, не всегда.

Для успешного выполнения проекта в команде должны быть представлены все роли, необходимые для этого. Здесь мы подходим к первому фактору, который влияет на ответ на наш вопрос - специфика проекта. Если на проекте есть готовые требования, скорее всего, вашей команде не нужен человек, выполняющий роль BA (это не значит, что для успеха проекта совсем не нужен BA, просто его работа уже выполнена кем-то другим выше вашей команды), если вам прислали готовые документы по архитектуре и дизайну, значит, вам скорее всего не нужен SA, если проект технически не слишком сложен, возможно, вам достаточно не самой сильной команды, но роль DL все равно придется на кого-то возложить, и этот "кто-то" должен соответствовать уровню этой роли.

Таким образом, если в команде есть кому занять роли DL, QAL, SA, BA (а также роли программистов и QA :)), то на должность менеджера проекта можно поставить человека, у которого нет опыта программирования, тестирования, бизнес-анализа, написания документации, но который будет заниматься исключительно менеджерскими активностями, которых тоже очень много. И, как показывает практика, профессионализм и сильный уровень в этих активностях зачастую еще более редки, чем профессионализм и желание постоянно повышать свой уровень у программиста.

Еще один немаловажный фактор, который определяет, какие роли будет выполнять человек на должности менеджера проекта - это размер проекта. На небольшом проекте особо не разгуляешься. Если каждому человеку в команде назначить одну роль, то будет, как на картинке, где один копает, а остальные смотрят :), потому что объем "чистых" активностей одной роли невелик или продолжается незначительный период времени, а работы по разработке или тестированию продукта очень много. Поэтому очень часто на небольших проектах PM (или уже скорее PL) выполняет не только менеджерские функции, но еще и является основным техническим специалистом на проекте, который и анализирует требования, и пишет спецификации, и продумывает архитектуру, и руководит тестированием, в общем, и швец, и жнец. Не говоря уже о том, что в таком случае разработка выходит намного дешевле, т.к. достаточно взять одного самородка, дать ему в команду 25 джуниоров - и дело пойдет ;) Шучу, конечно, но в каждой шутке, как известно, доля шутки - я такие ситуации видел не раз. Поэтому это тоже нужно учитывать.

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

Таким образом, нетехническому PM часто приходится так или иначе вникать в технические детали, но если он умеет правильно наладить коммуникации и работать с людьми, это не должно создавать для него особых проблем. И это подводит нас к следующему вопросу.

Есть ли минимальный набор "технических" знаний, необходимых PM?

На мой взгляд, хороший менеджер проекта, при условии заполнения остальных ролей другими членами команды, не обязан знать программирование или тестирование даже на минимальном уровне. НО (!) он все-таки должен хотя бы на каком-то уровне понимать, что такое разработка ПО, какие процессы в него вовлечены, в каком порядке и почему, что такое требования и запросы на изменение функциональности (change requests), как с ними работать, что такое качество продукта, что делают те или иные члены команды, в конце-концов. То есть, по сути, понимать специфику разработки ПО. Во всем остальном ему помогут другие члены команды.

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

Так, может, лучше взять DL или QAL и сделать менеджера проекта из них?

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

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

Насколько мне известно, на западе сейчас довольно активно пытаются внедрять в работу "нетехнических" менеджеров, поскольку у людей, обогащенных техническим опытом, точно такое же количество проблем при переходе на медеджерские должности, что и у "нетехнических" менеджеров проектов, которые сталкиваются с техническими вопросами. Более того, у PM вообще своя карьерная лестница, идущая параллельно технической лестнице. Так 100% работает Microsoft, наверняка, и другие крупные (и не только) компании. В таком случае у технического специалиста есть возможность развиваться технически по-максимуму, в том числе и по зарплате, а вот как раз выход на параллельную лестницу, как правило, означает снижение зарплаты, потому что твой текущий менеджерский уровень еще очень низок по сравнению с теми, кто имеет в этом вопрос намного больше опыта.

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

Успехов вам!

PS. Еще раз спасибо всем, кого я доставал своими глупыми вопросами :)

Снова об IT-образовании

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

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

Программирование и "промышленная" разработка софта - это, как говорится, две большие разницы. Хороший "промышленный" программист (как и любой другой специалист) - это не только технически подкованный программист, но еще и грамотный, ответственный, умеющий работать в команде работник. У вузов же задача другая - они не конвейерных рабочих готовят для ублажения нашего родного аутсорсового бизнеса (т.е. по принципу ПТУ), а стараются, кроме непосредственно программирования, научить человека еще и другим важным предметам. Да, не все из них понадобятся в жизни. Да, образовательно-техническая база устарела. Да, действительно хороших преподавателей мало. И наконец, да, программистов нужно учить по-другому. Все эти проблемы есть. Но только решение их нужно искать не с точки зрения "а вот нам сейчас нужны PHP-девелоперы, давайте нам их, и побольше", как того требует рынок, и не с точки зрения "забрать студента как можно раньше, пока вуз его окончательно не развратил" а все-таки с точки зрения реформирования наших вузов для того, чтобы на выходе они давали хорошо подкованных CS-специалистов, которые будут:

1. знать техническую базу: устройство компьютера, микропроцессора, и т.д., понимать, что такое ОС, как работают компьютерные сети, что такое интернет
2. уметь программировать (язык не важен, важно понимание и алгоритмическое мышление)
3. знать алгоритмическую базу, структуры данных, базы знаний, основы нейросетей, искусственного интеллекта, и т.д.
4. понимать, что такое качество кода, ООП, шаблоны проектирования, масштабирование, производительность и т.д.
5. знать хотя бы по одному языку программирования разных уровней, и те или иные технологии по выбору студента и на том уровне, который он хочет знать
6. разбираться в базах данных (реляционных, объектных), XML и других форматах и способах хранения данных
7. понимать весь цикл разработки софта (а не просто уметь писать лабы), иметь представление о методологиях разработки, командной работе, QA
8. быть немного знакомым с best practices of software development: source controls, unit testing, CI, и др., возможно - BDD, DDD, XP-практиками
9. наверняка, что-то забыл, впишите сами...

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

Это, конечно, не все. Со стороны вузов еще нужно перенимать опыт коллег (МГУ, MIT, etc.), хотя бы лекции их посмотреть, отправлять преподавателей на стажировку. Заинтересовывать студентов действительно интересными научными разработками. Брать заказы и гранты у крупных госорганизаций и не только у них. Обновить подходы к обучению программированию, продумать и улучшить программу. Дать студентам бОльшую гибкость в выборе "специальных" предметов: один может хотеть изучать веб-программирование, второй - мобильные системы, а третий - робототехнику, одному нравится LAMP, второму - .NET, третьему - Ruby on Rails. Постоянно держать связь с IT-индустрией нашей страны.

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

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

Летаргический сон украинского .NET-сообщества

С сожалением вынужден констатировать, что украинское .NET-сообщество либо мертво, либо находится в глубокой и беспробудной спячке. Откуда такие неутешительные выводы? Да так, личные наблюдения. Скажите, пожалуйста, проходила ли когда-нибудь в Украине нормальная полноценная .NET-конференция? Нет, я не про DevDays, которые, надо признаться, в этом году в Киеве уже были похожи хотя бы на что-то более-менее взрослое, а не на обычную рекламу последних разработок Microsoft. Я про что-то более реальное, более осязаемое, с серьезными темами и докладами, с серьезными докладчиками. А давно ли к нам с докладами наведывались реальные девелоперы из Microsoft или хотя бы из западного сообщества? Говорите, что им тут делать, они по таким мероприятиям не ездят? А если я вам скажу, что многие из них ездят не только в Европу или там Австралию, но и в Южную Африку, Египет, Пакистан, Турцию, Болгарию, Ливан? А потом делятся в подкастах, что, мол, вот какая в Софии была классная конференция, а в Пакистане у нас аж 3-тысячная аудитория была. И в Россию приезжают, что делает честь нашим северным соседям не только потому, что они их приглашают, но и потому что они способны организовать что-то серьезное, вроде той же Платформы, РИТ или других конференций. Да, это еще не PDC, но это уже хоть что-то, вы не находите? Хорошо, а много ли у нас других конференций или встреч? Не знаю, как в Киеве или Львове, а вот в Харькове есть еще IT Talk'и, которые проводятся под чутким руководством Жени Устименкова, встречи UNETA, которые были бы невозможны без Вовы Лещинского и еще нескольких человек, за что им честь и хвала, и все. Да, еще иногда заезжают с приветом из Киева QA Club и Agile Gathering. Вот теперь точно все! А теперь еще одно задание: скажите, пожалуйста, сколько вы знаете украинских .NET-блоггеров, которых интересно читать. Много насчитали? Угу, вот мне тоже как-то пальцев на двух руках хватило...

С чего это я так разошелся? Да, кто его знает, наболело, наверно. Вчера в Харькове на чем-то наподобие DevDays были доклады по Windows Azure. Знаете, сколько было людей? Человек 50, не больше. Из них человек 30 - знакомые лица со встреч UNETA, то есть костяк, который ходит на все подобные мероприятия. И это в городе, где по самым скромным подсчетам больше 2 тысяч .NET-разработчиков. А почему? А потому что: а) реклама мероприятия была дана меньше чем за неделю до его проведения и прошла, по-моему, только по рассылке dev.net.ua, многие мои друзья даже не знали о том, что что-то будет, б) в Харькове у людей неоднозначное мнение об уровне подобных мероприятий: серьезные разработчики предпочитают их игнорировать, как и встречи UNETA, которые в последние несколько лет превратились в собрания студентов. Ну что за организация, в самом деле?! Почему подобные мероприятия не анонсируются как-то более серьезно, почему не рассылается реклама по разным фирмам, почему GlobalLogic может собрать пару тысяч человек на Программанию (пусть большинство из них студенты - не важно), а Microsoft Украина - нет? Ну да ладно, проблему с рекламой поправить не сложно. А вот как доказать сильным разработчикам и их работодателям, что этот день (или вечер) пройдет для них не зря? Что они услышат интересные доклады, из которых смогут узнать что-то новое для себя, что-то, что им поможет в их работе. Что они смогут встретиться с интересными людьми, пообщаться, поделиться опытом и приобрести его. Что они смогут сами поучаствовать в докладах, если видят в себе силы и имеют желание! И не говорите мне, что у нас нет ребят, способных на это. Только в одном Харькове среди моих близких и дальних знакомых я знаю десятки подобных людей, которые просто не хотят ходить на наши “местные” конференции из-за их слабого уровня.

Как, в конце-концов, сформировать в Украине или отдельно взятом городе настоящее сообщество, которое сможет не просто вместе двигаться вперед, но и двигать вперед всю отечественную разработку? Может, стоит обратиться за опытом к профессионалам хотя бы того же Microsoft, которые уже собаку съели на этих вопросах и построили у себя в Штатах или Европе реально сильные сообщества. Ведь все реально, было бы только желание. Существуют же online-сообщества типа того же RSDN уже в течение многих лет, и держаться как-то. Так чем мы хуже-то?

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

Дао программиста

Думаю, каждый программист в своей работе уже определил для себя, что программирование состоит как минимум из двух компонентов: технологий и подходов (возможно, не самое лучшее слово для описания данного термина, но лучше термин я не нашел).

Технологии определяют “чем” мы работаем, т.е. это набор инструментов: языки программирования, базы данных, среды, тулзы, библиотеки классов, фреймворки, компоненты и т.д. То есть, если взять аналогию с токарем, это те инструменты и материальные приспособления, которые он использует для изготовления деталей.

Подходы же определяют “как” мы используем все эти инструменты и пишем код, т.е. в случае программирования это понимание и правильное использование ООП, SOLID, паттернов проектирования (GoF, Fowler), каких-то других Patterns & Best Practices, архитектурных принципов, рефакторинга, алгоритмов, структур данных и т.д. Сюда же можно отнести и знание и использование таких практик, как TDD, DDD и пр. В том числе это и тот опыт, который мы приобретаем в процессе работы. В случае с токарем это его умение вытачивать те или иные детали, которое он тоже совершенствует.

У каждого программиста эти 2 компонента развиты в разных соотношениях. Есть ребята гармонично развитые, которые, например, не только знают о том, что есть такая штука как ООП, но и правильно его используют. Есть отклонения в ту или иную сторону.

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

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

Неужели это конец развития? Нет, конечно, это только начало. Во-первых, нет предела совершенству, и знание и понимание тех же технологий можно и нужно увеличивать. А во-вторых, когда программист переходит на уровень архитекта, у него начинаются уже свои головные боли и дальнейшее развитие, но уже не как программиста. Есть application architect, solution architect, enterprise architect, etc. и у каждого свои навыки и знания. Про дао архитекта я пока написать не могу, извините, не дорос еще :) Но оно есть, я в этом уверен.

К чему я все это веду? К тому, чтобы все понимали, что в работе программиста важны и технологии, и подходы, что даже отличное знание технологий еще не делает программиста инженером. На одном крыле далеко не улетишь. Ну и чтобы каждый мог понять хотя бы приблизительно, на каком уровне он сейчас находится и увидел, что именно нужно развивать. Благо, книги есть не только по технологиям, но и по подходам. Изучайте ООП, паттерны, рефакторинг, всякие TDD/DDD/Agile/прочее, это чужой опыт, который может помочь вам стать настоящим профессионалом. Успехов!

IT-образование vs. профессиональный рынок

К написанию следующей заметки меня подтолкнула статья Виктора Ивановича Каука, к.т.н., директора Центра технологий дистанционного обучения Харьковского национального университета радиоэлектроники о проблемах подготовки кадров для IT-отрасли, ссылку на которую Паша Подлипенский разместил и снабдил комментариями в своем блоге. Меня эта тема также волнует уже очень давно, т.к. я только относительно недавно сам был студентом ХНУРЭ и видел все происходящее с нами и университетом своими глазами. Более того, я был активным участником данного действа, и мне бы хотелось высказать свои мысли по этому вопросу.

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

Итак, у нас есть три действующих лица: вуз, коммерческие IT-фирмы и студенты. Причем говорить я буду не обо всех студентах, а лишь о тех, о ком говорит Виктор Иванович – о тех 10-20%, которые находят себе работу по специальности, еще обучаясь в университете. Исходя из своего опыта (я учился на кафедре Программного обеспечения автоматизированных систем, на потоке численностью около 180 человек, «работал» в университете с первого курса и после третьего ушел работать в крупную IT-компанию города Харькова) я могу сказать, что я наблюдал 2 волны оттока студентов. Первая волна началась где-то с начала третьего курса и закончилась где-то на четвертом. Если не считать тех единиц, которые пошли работать на 1-2 курсах, здесь ушло порядка 15-20 человек, т.е. где-то 10% потока. Связана первая волна была с тем, что 1) толковые ребята поднабрались уже достаточно опыта в вузе и шабашках, чтобы попробовать свои силы, 2) у них появились запросы, требующие финансов, и 3) многие из них попали на практику в коммерческие фирмы, после которой они там и остались. Потом в течение полугода-года опять же устраивались на работу единицы, а где-то с середины 5-го курса, когда начался диплом, пошла вторая волна, которая захватила еще где-то человек 10-15. Общее количество работающих на потоке приблизилось к 20-25%. После окончания вуза работать по специальности (в той или иной мере) пошли еще наверно процентов 10. Остальные работают не по специальности. Но разговор сейчас не о тех, кто нашли работу после вуза, а о тех, кто, по сути, частично бросил обучение с различными целями.

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

Итак, почему толковый студент-программист хочет идти работать:

1. хочет найти применение тем знаниям и опыту, что у него уже есть (есть у человека стремление к самовыражению, есть)
2. хочет быстрее получить более серьезные знания в реальной работе, т.к. он этого не может получить в вузе, где дают широкие, но неглубокие знания
3. хочет получить опыт реальной работы, т.к. это ему пригодится после вуза
4. хочет начать зарабатывать деньги, причем не такие и маленькие, т.к. запросы уже выросли, а стипендия – нет (или ее и не было), хочет стать финансово независимым
5. и, да, как правильно отметил Виктор Иванович, иногда хочет просто казаться взрослым и шарящим, мол, меня вот взяли, я работаю, я умный

Чего хочет вуз и преподаватели:

1. дать своим студентам максимально качественное образование
2. трудоустроить студентов после окончания вуза (есть такое требование Минобразования, насколько я знаю)
3. высокой посещаемости студентами занятий
4. проведения совместных исследовательских работ, т.к. у преподавателей на это зачастую просто не остается времени, им нужны помощники и исполнители, не говоря уже о том, что часто они просто исследователи в душе
5. привлечения самых толковых ребят в аспирантуру с прицелом на работу в вузе

Чего хотят коммерческие фирмы в условиях большого спроса на специалистов:

1. получать после вуза хорошо подкованных специалистов в достаточных количествах, которых не нужно переучивать или учить с нуля
2. лучше получать специалистов средних, но много, чем действительно классных, но мало, т.к. специфика аутсорсинг-проектов, как правило, не требует много асов, она требует одного-двух асов и кучу хороших исполнителей
3. успеть забрать самых лучших на работу именно к себе, т.к. в противном случае они будут работать на других, а тебе останутся ребята послабее
4. дать возможность работающим у них студентам не тратить много времени на учебу, т.к. это отвлекает их от реальной работы, которая приносит прибыль фирме
5. не давать особой возможности студентам работать на полставки (есть фирмы-исключения, но их не так много), т.к. такую работу сложнее координировать, планировать и, в конечном счете, продать конечному клиенту

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

К сожалению, состояние нашего государства сейчас таково, что ему плевать на все эти проблемы. Какие там стипендии, гранты, какие там исследования. Я считаю, что IT-отрасль в Украине существует во многом не благодаря, а вопреки. В то же время, я уверен, что если бы в университете была интересная исследовательская работа, подкрепленная именными стипендиями, грантами и неким подобием зарплат, многие из тех, кто ушел работать, подумали бы 30 раз, прежде чем сделать это. Не знаю, кто как, а я уже насмотрелся на эти однообразные аутсорсовые приложения, в которых можно найти в лучшем случае технологический интерес, но уж никак не исследовательский (что бы там кто ни говорил, а настоящего R&D в аутсорсовых проектах, как кот наплакал). Если бы мне сейчас предложили программировать роботов, системы с элементами ИИ или спутники, я бы пошел, не раздумывая. А если бы это предложили в университете, это был бы вообще предел мечтаний. По крайней мере, часть людей, которым это действительно интересно, остались бы и могли бы заниматься тем, что им нравится, и не факт, что с меньшими зарплатами и перспективами.

Решение мне видится достаточно простым в формулировке, но в то же время ужасно сложным в реализации. Мне очень нравится фраза о том, что «настоящий учитель – это тот, кто умеет сначала разбудить любопытство, а потом его удовлетворить». Так и здесь, преподаватели должны суметь разбудить студентов, причем не только тех, кого называют толковыми, а вообще большинство из них. Разбудить их интересными задачами, совместными исследованиями, перспективами. Как это сделать?

1. С ранних курсов стараться занимать студентов на различных внутренних проектах вуза, как учебных, так и практических, в рамках изучаемых ими дисциплин. При этом не нужны эти искусственные курсовые и лабы. IT – это новый век, здесь нужны новые подходы. В разных вузах используются экспериментальные подходы по обучению студентов программированию, когда пишутся проекты целыми группами студентов, максимально приближенно к реальности.
2. Давать студентам по-возможности полные и последние знания, чтобы им было интересно ходить на занятия. Чтобы они знали, что они могут и там могут научиться чему-то полезному, а не только «на улице». Постоянно совершенствовать свои знания и умения, чтобы быть «в струе».
3. Стимулировать внеклассные, факультативные занятия на различную тематику.
4. Проводить в рамках вуза различные конференции, форумы, приглашать признанных специалистов, чтобы заинтересовать, зажечь людей.
5. Проводить олимпиады по программированию, конкурсы научных работ, отправлять ребят с их работами в другие города, за границу. Пусть посмотрят мир.
6. Стимулировать исследовательскую работу. Искать реальные, интересные проекты, желательно оплачиваемые, и решать их силами студентов и кафедры. Создавать исследовательские центры внутри вуза, получать гранты и т.д.
7. Отправлять талантливых ребят (а не тех, кто заплатил, как у нас часто случается) учится по обмену за границу, выполнять там какую-то исследовательскую работу. В общем, активизировать связи с другими вузами и двигаться в этом направлении.
8. Поощрять ребят, добивающихся успехов, стимулируя и подстегивая тем самым остальных.
9. Сделать будущую возможную работу в аспирантуре максимально привлекательной для студентов, причем не только в финансовом плане.
10. И так далее, думаю, основная идея понятна, а дальше можно развивать фантазию.

Да, эти меры не дадут 100%-го возврата людей в вуз, но они, по крайней мере, оставят тех, кто бы действительно хотел бы заниматься наукой и исследованиями, в вузе, а также, возможно, повысили бы те 20-30% работающих в результате по специальности ребят еще раза в полтора-два. Разве овчинка не стоит выделки? И, что удивительно, это выгодно не только вузам, но также и коммерческим фирмам, не говоря уже о студентах.

IT-отрасль и финансовый кризис

Сейчас о финансовом кризисе не говорит и не пишет разве что ленивый. Мы тут с другом тоже на досуге поразмыслили над тем, что несет финансовый кризис индустрии разработки ПО в целом и аутсорсингу ПО в частности.

Disclaimer. Эти размышления не претендуют на истину в последней инстанции, более того, они касаются в основном рынка разработки ПО города Харькова, хотя, думаю, их можно аппроксимировать как минимум на всю Украину, а, возможно, даже и на все постсоветское пространство.

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

Причины и следствия

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

Чем это грозит простым труженикам клавиатуры и мышки?

Теперь посмотрим на то, чем это грозит всем нам. На мой взгляд, потенциально возможны как минимум 2 этапа перед тем, как ситуация снова вернется в старую колею: 1) остановка развития и 2) деградация. Заденут ли нас оба этапа или ситуация успеет нормализироваться до наступления второго – это очень интересный вопрос.

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

Второй этап будет намного хуже, чем первый. И начнется он, если, не дай Бог, клиенты начнут банкротиться или сворачивать проекты. Судя по тому, что аналитики прогнозируют пик кризиса на начало 2009 года, это может начаться именно тогда. А может и не начаться – я не специалист, чтобы ответить на этот вопрос. Однако, чисто гипотетически, ЕСЛИ такое произойдет, то всем нам это грозит двумя вещами: 1) начнутся массовые увольнения вследствие закрытия целых проектов, которые увеличат предложение на рынке, при этом спрос будет почти равен нулю, 2) будут понижения зарплат, если уж не для текущих сотрудников, то, по крайней мере, для тех, кого принимают на работу. Средние зарплаты начнут падать.

Так что, о постоянных существенных повышениях зарплат (за 4 года, которые я слежу за рынком, средние зарплаты в аутсорсовых компаниях повысились в 4-8 раза) и легких переходах с места на место можно забыть. Кроме того, возможно обострение противоречий между сотрудниками компаний и их владельцами. Понять можно и тех, и других: обеим сторонам будут нужны деньги, чтобы выжить. Вот только для первых это означает увеличение зарплаты, а для вторых - уменьшение расходов, в том числе и на зарплату. Если вам повезло, и вы нашли хорошее место работы с достойной зарплатой – good for you. Возможно, нас всех пронесет на этот раз, а возможно, и нет, и мы получим еще один 2000-2002 год, когда зарплаты держались на уровне 200-400 долларов, а новых сотрудников предпочитали не нанимать.

Как пережить смутные времена?

Ответ прост – быть действительно эффективным, полезным и перспективным на своем месте работы. Да, это клише, которое подходит и для не-кризиса. Однако сейчас это клише приобретает другой оттенок.

Быть эффективным и полезным – это значит не просто делать свою работу, но делать ее быстро, качественно, ответственно и, что самое главное, добиваться положительного результата. Про эффективность хорошо написал Сергей Розовик. Если вы привыкли часть рабочего времени посвящать социальным сетям или башоргу – пора отучиться от этой вредной привычки. Если вы привыкли работать расслабленно, спустя рукава – почитайте про «7 навыков высокоэффективных людей», статьи о лайфхакинге и других способах повышения личной производительности и эффективности. Если у вас есть проблемы на проекте – надо задуматься об их причинах и устранить их.

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

Ну, и последний совет. Финансовый кризис ударит по нам не только со стороны работы, но и стороны нашей повседневной жизни. Проанализируйте ситуацию и советы аналитиков о том, что нужно делать с лежащими на депозитах деньгами, счетами, кредитами. Запасайтесь картошкой :) Отучите себя наконец-то брать потребительские кредиты! А если нужен кредит на машину/квартиру, то лучше повременить. Еще о стратегиях выживания во время кризиса можно почитать у Макса Крайнова, а можно найти и другие – благо их сейчас полно.

Какие будут результаты

Конечно, все это мы переживем. Человечество переживало и более серьезные кризисы и решало более серьезные проблемы, чем эти. На глобальном уровне сейчас мы наблюдаем реформу мировой экономики и финансового сектора, а также зарождение нового мирового порядка. И я думаю, что это к лучшему. Это как болезнь, которая дает возможность остановиться и проанализировать свою жизнь, что ты делаешь не так и что нужно исправить, только болезнь эта всего человечества и нам всем с ней бороться.

На локальном же уровне в нашей отрасли наверняка произойдут следующие вещи:

1) Произойдет естественный отбор, количество компаний на рынке сократиться, исчезнут самые слабые и неприспособленные

2) Выжившие компании сбросят лишний вес, который им мешал развиваться дальше, станут более гибкими и устойчивыми (почитайте, например, книгу Луиса Герстнера «Кто сказал что слоны не умеют танцевать?» о том, как IBM вышла из крутого пике в начале 90-х годов)

3) Рынок IT-специалистов стабилизируется, зарплаты перестанут расти неимоверными скачками, а сами специалисты станут умнее и профессиональнее.

4) Вполне возможно, что государство наконец-то обратит свое внимание на IT-сферу и у нас наконец-то появиться нормальные законы, регулирующие рынок, упрощающие развитие и улучшающие конкурентоспособность наших компаний (как в Индии, например)

Еще немного о кризисе понятными словами можно прочитать здесь:

Понятно о кризисе
Экономический кризис на пальцах
Прививка от идиотизма