вторник, 6 мая 2014 г.

Кирпичики 1

Что такое опыт для программиста или менеджера? Почти в каждой вакансии мы читаем о том, что нужен опыт от N лет. Но из чего состоит этот опыт?

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

Опыт состоит как бы из кирпичиков. И из них можно быстро и качественно построить часть нового проекта. Попробую описать тот опыт и те кирпичики, которые накопились у меня. Сразу оговорюсь, что моя стезя - это продуктовая разработка, а продукты сосредоточены в русле Windows и последнее время используют .NET\C#. Я условно разделю свои "кирпичики" на технические и организационные и начну с общих вопросов.

THE TEAM


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

Мне нравится работать с молодыми и активными ребятами, но в то же время брать совсем вчерашних студентов, мне кажется слишком рискованным. Лично у меня наиболее удачным срезом для поиска новых членов команды являются ребята до 30 лет с опытом работы около 3х лет. У них уже есть какой-то опыт за плечами, и в то же время они еще не устали и не обросли непоколебимыми убеждениями. Они хорошо учатся, с радостью осваивают новое и весьма быстро становятся незаменимыми членами команды. Так же учитывая гибкую природу нашей работы, где важно мнение каждого члена команды, человек должен быть коммуникабелен.

МЕСТО


Рабочее место имеет огромное значение. Идеально когда каждая команда имеет свое помещение. Полный open-space мешает сосредоточится и в то же время не дает командам собираться вместе иначе как в переговорках. Отдельные же кубики мешают образованию команды. Порою жители кубиков даже спустя годы не знают своих соседей.

Имея свое помещение, команда может не только проводить спонтанные брейнштормы не мешая окружающим, но и использовать стены для размещения схем, белых досок и scrum-board.  Когда своего помещения нет, люди вынуждены придумывать всякие хитрости. Например, я знаю один open-space офис, где каждая команда каждый день приносит свою SCRUM-доску в переговорку на время стендапа.

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

Так же я не могу себе представить современный IT офис, в котором нет нормального WiFi, который открыт не 24h в сутки и к которому у сотрудников нет возможности подключаться через VPN.

Но, как ни странно, я все еще слышу об офисах, в которых программисты работают с 9 до 18, где на ночь просят выключать компьютеры, опечатывать комнаты и сдавать съемные диски под роспись. Мне удивительно, что так еще кто-то работает. :)

Кстати о времени работы. Опросы коллег показывают, что они оценивают свободный график, возможность поработать из дома и легко перенести отпуск в сумму равную 20% зарплаты.... Лично я вряд ли уже соглашусь работать с 9 до 18 - это адски неудобно. :)

ПЛЮШКИ


Сейчас картина рынка ИТ-вакансий на стороне работников: вакансий больше, чем реальных кандидатов. Это приводит не только к росту зарплат, но и к тому, что компании пытаются привлекать сотрудников не только деньгами, но и прочими "плюшками". Для себя я понял, что из плюшек важны относительно свободный график, парковка (увы, это большая редкость в больших городах), страховки для себя и семьи и увеличенный отпуск (например 36 дней против стандартных 28). Ну и самая главная плюшка - это дружный коллектив и адекватное руководство.

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

ЖЕЛЕЗО


На мой взгляд, чрезвычайно важно иметь качественные машины для разработчиков. Если процесс сборки, запуска тестов и отладки работает медленно, то не надо питать иллюзии - на них очень быстро забьют. В результате разработчики будут чекинить код, который даже не собирается.
Так же очень важно позволить разработчикам иметь сносные виртуальные машины, легко их поднимать, откатывать и настраивать. В противном случае ответ: "А на моей машине все работает!", будет вполне легитимным.
  Для примера: сейчас у нас на проекте есть более дюжины серверов в стойках, на которых стоит Hyper-V, и любой разработчик может использовать как имеющиеся там виртуалки, так и с легкостью поднимать новые для любых нужд. Я считаю эту ситуацию просто идеальной.
Умение конфигурировать систему, ставить свой продукт и понимать его требования к системе очень помогают в разработке и отладке.
 Кстати о Hyper-V. Я пришел к нему пройдя VMWare Server и VMWare ESXi и пока не жалею. Лично для меня основным драйвером к переходу с ESXi стал тот факт, что бесплатная версия ESXi не поддерживает автоматизацию запуска\остановки\отката машин и не имеет единой морды для всех серверов разом. Hyper-V же все это прекрасно поддерживает, а учитывая, что в рамках MSDN подписки есть тот же SCVMM, то пользоваться им удобно. Так же мне как давнему пользователю Windows гораздо легче управлять такими серверами через привычные интерфейсы. В плане же быстродействия у меня сложилось ощущение, что Windows машины под управлением Hyper-V работают чуть быстрее и меньше подвержены деградации производительности со временем.

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

Увы, я часто слышу, что разработчики вынуждены поднимать виртуалки прямо у себя на машинах. Особенно это грустно видеть при работе с тяжелыми системами типа SharePoint, Exchange, AD etc, где для полноценной работы надо иметь далеко не одну виртуальную машину.

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

Спасибо за внимание.

4 комментария:

Eduard Kibort комментирует...

Интересно. +1 ко всем пунктам. Жаль, что у нас вот с железом хреновато. А так все похоже.

Eduard Kibort комментирует...

Дык Amazon EC2 вам в помощь.

Eduard Kibort комментирует...

на нем виртуальный Hyper-V не разогнать, а без этого он нам бесполезный

Eduard Kibort комментирует...

Ну это у вас уж очень специфичный кейс. Большинству такие извращения не нужны. :)