разработка

графика

продвижение и PR

будни разработки

обзоры

IT офис

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

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

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

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

Понятное дело, что на низкую оплату высококвалифицированный программер даже не посмотрит. А кто посмотрит? Тот, у кого на данный момент времени зарплата ещё ниже или отсутствует вообще. Т.е. не востребованный (на данный момент) разработчик. Здесь есть два варианта:

Человек вообще не должен быть разработчиком, и тем, что он, не смотря на все неудачные проекты, по какой-то причине цепляется за эту отрасль, он дико травмирует собственную карму, отказывается признаться самому себе, что в менее престижной (и не обязательно менее), другой какой-то области он, вероятно, добьётся больших успехов. И все равно пытается доказать себе и всему миру - что он РАЗРАБОТЧИК. Эх, это ужасный тип людей, их так жалко :( всё равно приходится увольнять, иногда с половины проекта. Иногда тянут какую-то малозначимую задачку, из месяца в месяц теряя позиции, авторитет среди сотрудников и самоуважение.
Человек вполне может КОГДА-НИБУДЬ стать неплохим разработчиком. И всячески стремится к этому. Так стремится, что даже по этому поводу поступил в ВУЗ, где и обучается данной специальности. Но студенты не любят быть бедными, ибо возраст такой - денег нужно на всё и побольше, когда же еще так погулять можно будет? Да и более практичные причины - как можно быстрее получить реальный опыт по будущей специальности - побуждают их искать работу, даже если знаний в голове - на основы синтаксиса, а опыта - может, чуть поболе, чем Hello, Word! Самое оно для тех самых работодателей, которые гордятся тем, что платят своим сотрудникам немного поболе, чем объявленный в новостях по TV прожиточный минимум в регионе.

И такая вот команда из нескольких неопытных и нескольких бесперспективных "специалистов", обложившись учебниками по С и дотнету, принимается за проект, по которому им задание поставлено в формате "посмотрите, как сделаны подобные проекты вот по такой-то ссылке и по такой-то, скачайте вот эти пару утилит, и сделайте то же самое, только НАМНОГО ЛУЧШЕ".
Ой, не говорите, что не видели своими глазами такие команды и таких работодателей. Или вам очень повезло, или вы к IT отношения не имеете.

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

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

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

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

И другая модель. Мы за копеечную себестоимость будем делать проекты (той командой, которая согласится работать за копеечную же зарплату). Мы будем делать много проектов. Подсчитывать цели, сложности и риски мы не будем, просто делать,делать чтобы не стоять на месте. Аналитика? Ой,ребята, вы же такие умные, придумайте что-нибудь, посмотрите, КАК ЭТО СДЕЛАНО У ДРУГИХ И СДЕЛАЙТЕ ЛУЧШЕ. И так по кругу, без конца, в надежде, что одна из пустышек "выстрелит" и принесёт кучу бабла. Одна из причин, почему эта надежда не умирает - потому что один раз так уже произошло, и весь бизнес работодателя на сегодняшний день строится на бюджете с этой выстрелившей пустышки, в которой - пока занимались - никто серьёзного будущего не видел, и вложено труда было от нескольких малограматных программистов и одного удачливого менеджера, которому ПОВЕЗЛО.

В копилку речь одного директора:

По большому счёту мне не особенно важно, чтобы вы были в офисе к 9 утра - приходите хоть к часу дня (временная разница с ним - семь часов, и для синхронизации работы лучше бы приходить в три и уходить в час ночи). Мне не особенно важно, сколько часов вы работаете, отрабатываете положенные 8, или 4-6, или 10-12 - мне главное, чтобы была выполнена объявленная работа.
У нас бывают авралы, когда работать приходится много больше, и есть лёгкие дни, когда работы практически нет. В среднем оно то на то и приходится - нагрузка уравнивается. Если же по какой-то причине разработчику приходится сидеть больше 8 часов над работой - к примеру, в силу его непроходимой тупости или ошибок - пусть сидит и переделывает сам в счёт своего времени.

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

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

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

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

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

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

В одном из прошлогодних декабрьских постов я рассказывала о том, что в конце года мы заполняли некое "review" для наших заокеанских работодателей, где можно было в специально отведённых полях описать всяческие пожелания/рекомендации по усовершенствованию работы фирмы (на будущий год). Там я и написала, что нашей фирме "Need Analitic Manager (qualified, hightskill)", и на войсовом собеседовании с руководством (оно, в общем и целом, было просто голосовым обсуждением отосланного по мейлу review) наш руководитель долго пытал меня - что я, собственно, имею ввиду и зачем нам, собственно, такой специалист. И вот что удивительно. По окончании собеседования он меня практически убедил в том, что аналитик - это какой-то бесполезный атавизм, бессмысленный пожиратель денег и времени, и вся работа без специально заточенного аналитика выполняется превосходно.

А теперь я поняла в чём дело! Я же по-просту оскорбила нашего руководителя - он-то считал, что всю работу аналитика он выполняет, и причём успешно... Ну что же это я так... ещё бы уволиться ему предложила. Нехорошо.

Последующий же анализ (техническая сторона проекта) обязан просто ложиться на разработчика - всё, что касается выбора платформы, инструментов разработки, проектирования системы (баз данных, модульной структуры, прочего, прочего). И по его логике выходит, что *кодеров* в нашей конторе быть не должно и близко - каждый первый обязан просто быть системным программистом, владеющим системным анализом, и при этом ещё и более чем образованным человеком - ибо разбираться придётся с таким количеством прикладных задач, от бухгалтерии и систем оплат до... бесконечности, в общем, потому как кухня может быть любой, и программисту даётся символически мало времени на то, чтобы въехать в тему.

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

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

На самом деле в любом проекте допустим некоторый процент костылей и подпорок, но такая система будет работать только в том случае, если руководство не провоцирует текучку кадров, серьёзно же расчитывать на помощь в проектировании со стороны конечных разработчиков, так же как и на бесконечное докостыливание в фоновом режиме - не солидно как-то. А так обычно получается, как в одном из законов Мерфи: "В каждой организации есть человек, который знает, что на самом деле происходит. Его-то и надо уволить" У нас как бы не увольняют, но создают атмосферу-условия, когда разработчик, на текущий момент самый грамотный и соображающий (и пытающийся всё-таки проявлять инициативу, участвовать в проектировании) уходит сам. В итоге: еправильная постановка (причём не в техническом смысле, а в искажённом описании задачи - когда задачи не тривиальные и общего образования программистам не достаточно для того, чтобы понять тему), а потом - это программисты виноваты, плохо сделали: под этим прессингом любые, самые талантливые разбегутся. Особенно при условии, что талантливые как раз видят слабые места, и видели в процессе, и - более того - озвучивали неоднократно, за что были осуждаемы тем же ответственным начальником - мол, сроки затягивают, скорости реакции сделать "по-быстрому" не хватает, лезут не в своё дело, сидели бы программировали... Про то, что программист *должен думать* - вспоминают тогда, когда проект уже измучен подпорками, а те программеры,которые начинали проект, давно сбежали на рыбные места.

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

Господа студенты-программисты. Вы наверное сейчас на чем свет стоит ругаете идиотов, которым в голову пришло в программу обучения технарей вставить такие гумманитарные и нетехнические предметы, как логика, социология, психология, правоведение, экономика, религиоведение, этика и эстетика. Конечно, гораздо ведь интереснее в это время изучать языки программирования, а потом гнуть пальцы перед друзьями, я мол знаю Яву или РНР. Конечно, эти предметы нередко преподают преподы что называется второго сорта, ибо знающий препод пойдет читать свой предмет в профильный вуз, а не к технарям. Но это не отменяет того факта, что предметы эти чрезвычайно полезны и нужны.
Вы ругаете на чем свет стоит логику? Однако не поленитесь, сходите в библиотеку, почитайте из каких этапов состоит решение логической задачи. Узнайте что такое системный подход. Вы можете "знать" любой язык программирование, но без системного подхода Вы так и останетесь обычным кодером. Собственно, если Вы уже изучили теорию программирования и умеете мыслить системно - совершенно по барабану какие языки программирования Вы знаете. Любой новый Вы сможете освоить за месяц максимум.
Вам кажется, что психология и социология - это для глупых блондинок? Однако подумайте, что в реальной жизни надо делать не курсовые и лабораторные в одиночку, а большие проекты целыми командами. Вам придется взаимодействовать с коллегами, разрешать конфликты и в дальнейшем, двигаясь по служебной лестнице, брать на себя руководство другими сотрудниками. Вы уверены, что Вашего здравого смысла хватит, чтобы осилить все это? Почему тогда так популярны книги ДеМарко и Рейнвотера?
Терпеть не можете экономику? А может Вам придется банковский или бухгалтерский софт писать? А там тысяча нюансов, и не всегда под рукой будет вменяемый аналитик. И сами бухгалтера далеко не всегда разбираются в том, чего они хотят от программы.
Этика и эстетика зачем? Объясняю. Несмотря на кажущуюся бездушность процесса программирования, на деле это довольно творческая профессия, так что чувство прекрасного хотя бы для того чтобы красиво оформлять код Вам явно не помешает. Ну и понимать, что этично, а что - нет, Вам тоже будет полезно для будущих гармоничных взаимоотношений в коллективе.

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

Еще можно заметить, что учёта и контроля за работой такой команды нет и быть не может. По нескольким причинам:

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

Поэтому мы исключаем team leader`а, project manager`а, и аналитика из команды в принципе, назначаем абстрактного техдиректора, которого обяжем держать в голове все текущие разработки и все направления (и задачи по каждому специалисту, разумеется) - чай, умненький мальчик, не порвется.

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

Что, опять проект не работает? Сроки не выдержали? Заказчик отказался? Выяснилось внезапно, что сервис никому не нужен?
Ха. Так это программисты виноваты. Плохая команда.

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

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

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

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

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

К примеру, контора А вырвалась вперёд конторы Б на 20% проектного и финансового уровня. По разным причинам:

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

А в это время ~~в замке~~ в некоей конторе Б - с меньшим уровнем проектов, зарплат и, возможно, худшими условиями труда, берут на работу программиста, ещё студента или младшего специалиста, ещё без скиллзов и реальных знаний. И вот он там трудится на скромной зарплате, читая по ходу дела документацию, обсуждая свои программерские проблемы на форумах и со старшими товарищами, делает один проект (с горем пополам, с матами PM и ежедневным недовольством заказчика), второй - уже покрасивше и по-увереннее, третий - вполне грамотно, успешно. Ему даже % на 10-20-30 повышают зарплату. И тут из конторы А, изначально более успешной, приходит информация о вакансии с з/п в два раза больше, главное условие - не ньюбам, а специалистам, которые уже имеют этот самый опыт. Долго будет раздумывать такой программер, оставаться ему в фирме Б в надежде, что она когда-нибудь вырастет до уровня А и его зарплата вырастет соответственно? Не-а, не долго, не больше 2-3 минут (собрать-обновить своё резюме и отправить по указанному адресу в фирму А заявку на собеседование).

Такое присходит постоянно. В сколько-нибудь крупном городе, где наличиствуют n-е количество подобных IT-контор, программеры мигрируют постоянно, и, причём, вовсе не всегда в одном направлении - вверх, потому что где гарантия, что в указанной выше фирме А не произойдёт креш, не уйдёт от них золотой заказчик и не наскучат они своему инвестору? Нет гарантий, потому и стабильности нет, и растут новые IT-конторы как грибы, и растворяются в неизвестности крупные фирмы, куда и попасть в своё время хотелось, и зарплаты там, и соцпакеты, и бассейн свой на крыше... где это всё?

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

Не так давно у нас ходил слух (вроде как не подтверждённый) о том, что ряд софтовых харьковских контор заключили между собой тайное соглашение, имеющее отношение именно вот к такой хаотичной миграции кадров. В частности речь шла о том, чтобы синхронизировать оплату программеров - junior developer'ов, senior developer'ов, аналитиков и дизайнеров - дабы не бегали за лишней сотней баксов к зарплате специалисты из одной конторы в другую, а если и объявлена по конкретной вакансии информация о зарплате большей, чем зарплата разработчика-специалиста в другой конторе (например, описанной Б, при этом состоящей в этой масонской группе, которая внутри себя поддерживает соглашение), то руководство Б может созвониться с руководством А и попросить - если специалист из Б по данной вакансии прийдёт на собеседование в А - чтобы его туда не брали. Уж не знаю, насколько это правда...

Это я всё к тому, что вчера переписывались с одним project-manager`ом не младшего звена из одной харьковской конторы - у них объявлены три вакансии разработчиков - сишников и дотнетчиков, он знает о моей конторе (фирма Б) и моих программерах, и просил... поискать среди наших желающих перейти к ним (фирма А). Разница про деньгам - именно те 10-20% вверх, по условиям труда - что-то лучше, что-то хуже, и я не враг людям, с которыми работаю, искренне желаю, чтобы зарабатывали они больше и работалось им легче... А вот жалко мне стало! Если согласятся уйти лучшие программеры - с кем останусь я? Худшие - с большой долей вероятности у них не пройдут собеседование (я до сих пор не понимаю, почему они сюда-то, в мою контору попали, тяжело с ними). Опять искать новых, опять обучать, срабатываться, закидывать ссылками на документацию, и после - отпускать в очередную фирму А на лучшие условия и большую зарплату? Тогда получается замкнутый круг для нашей конторы Б - на проектах студенческого уровня далеко не уедешь, а браться за серьёзные разработки - у разработчиков опыта не хватает, не успевают они его наработать, исчезают. А нет хороших заказов - нет повышений зарплат, условий труда и прочих радостей жизни.

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

С другой стороны - если упорядочить всё что можно - не занадто ли скучной станет жизнь разработчика?..

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

Статьи по теме:

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

наверх

Вукс Татьяна