Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Еще одна команда

За время моей работы в компании (а я уже задолбался считать, сколько я тут) полностью сменилось 3-4 команды, с которыми я работал. Про текучку в современном украинском IT все знают. Но я сейчас не про нее, родимую. Ни кого не удивишь тем, что люди приходят и уходят, это нормально, в общем. Но со временем, если есть большой и интересный проект, хороший ПМ и вменяемый заказчик, возникает более-менее стабильная команда, которая «сработалась». После «притирки», каких-то мелких разногласий вначале, после нескольких пережитых дедлайнов и факапов, после пьянок с заказчиками, остается группа людей, которым комфортно работать вместе. Это как хорошая бригада строителей — друг-друга понимают с полуслова, бригадира уважают/любят/побаиваются, ну и работу свою знают и делают с удовольствием. Такая команда может сделать очень многое. В огонь и в воду, как говорится. Умирающие проекты вытягиваются и полностью переписываются. Очень большие и сложные проекты. Да и любой стартап, думаю, будет просто как семечки.

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

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

У меня как раз ситуация наоборот — есть команда (почти фриланс) и набор проектов, часть в состоянии поддержки, часть активно развивается. Для заказчика конечно удобно то, что люди, которые начали разработку проекта 10 лет назад, всё ещё доступны и продолжают работать. Это и более выгодно ему экономически — с точки зрения наёма и обучения новых людей, особенно для проектов с количеством строк кода уходящим за миллион и десятилетней историей, существует проблема найти и обучить человека, так чтобы он вменяемо смог разрабатывать или поддерживать. Есть одно большое НО — разработчики тоже люди и кому то может банально надоесть заниматься одним и тем же, с одним и тем же заказчиком.

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

Мда... у нас так не принято...
Был не так давно на митинге, там представлялись люди из одной ненашей компании (причем хорошие специалисты):
— Я мол такой-то, работаю в XYX 15 лет.
— А я такой-то, работаю в XYX 10 лет.
— А я такой-то, работаю тут только 5 лет.
...
А я сижу и охреневаю....

Ну а почему у нас так не принято? Потому что во-первых IT компании не такие уж и «старые», а во-вторых — переход на другую работу — это почти единственный способ увеличить себе зарплату.

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

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

Команду тяжело впихнуть на проект. Ну представте, есть у вас слаженная команда, скажем 4 программиста, techQA, pm. А заказчик хочет, к примеру сначал двух прогеров, с возможностью наращивания (что с остальными делать?). Или 6 человек (новых людей добавлять). и так далее...

Проблема в том, что аутсорсят в основном вещи, на которые не хотят/не могут нанимать постоянных прогеров в головной офис. Если же продукт «выстрелил», то любой вменяемый руководитель будет стараться держать ядро разрабов под рукой, а не где-то там в Украине.

Заказчик хочет дешевые жопоместа, а не чтобы ему сделали проект. В этом по моему корень зла.

Ну почему же. Был случай, прибегали к услугам аутсорса. Нужно было 2 программиста для поддержки основной команды (на фичу). Нафига, спрашивается, мне целая команда была нужна? При том что юзер стори написаны, код ревью фигню не пропустит.

Насколько я знаю, некоторые бодишопы хотят сдавать команды целиком (им так тоже проще), но насколько у них это получается — я не знаю

И да, кстати, несколько человек из моего окружения (да и я сам) ушли из бодишопа, потому что проект просто наскучил. Так что это тоже не стоит сбрасывать со счетов.

Команду тяжело впихнуть на проект.
Так это именно потому, что бодижопская бизнес-модель. Клиент платит не за проект, а за «головы», которые ему «впихнули».
Для контраста предложу другую модель. У вас есть хорошая команда, которая способна за несколько месяцев написать мобильное клиент-сервер приложение «под ключ»? Так набирайте fixed price проекты, делайте и делите деньги на команду.
Но большие конторы так не делают. Им проще платить девелоперам ставку, с клиента брать за попа-часы, а разницу положить в карман. Стабильный профит и минимум риска.
Поэтому если вы команда и хотите работать вместе — так ищите подходящую контору, которая будет работать именно так, как вам удобно. Помните — это девелоперы зарабатывают деньги, а не менеджеры. Менеджеры нужны, что бы найти проекты и получить деньги. Так что можно посмотреть с другой стороны: это не контора нанимает команду, а команда нанимает контору для поиска себе работы.
Предложение: использовать Джина для поиска работы всей командой. Т.е. «продаваться» вместе и на конкретный проект. Думаю спрос будет. Особенно если команда имеет экспертизу в «популярной» области. Часто бывает что в конторе сэйлзы нашли интересный проект, но его не могут взять только потому что не успевают набрать нужную команду из своих свободных сотрудников. А тут готовая команда.

Ммм... fixed cost... Есть у меня мечта — делать fixed cost проекты. Но пока знаний не хватает, чтоб правильно оценить все риски (ПО, сцука, риско’вая). Вот вырасту — буду делать :)

А по джину — прикольная идея! Если сделать это правильно и не спутать с фриланс биржей...

Всё классно, но только на словах. Обьясню

1) Разные проекты, делаются разным колличеством людей. Есть даже такое понятие — оптимальное колличество работников на проекте. Что будет делать часть вашей команды мечты при простое?

2) Зарабатывает деньги тот, кто несёт ответственность. Кто в команде мечты будет попадать на деньги из-за программиста Васи, который заболел?

3) Выплывает из первых двух — как вы будете удерживать участников от внезапных «халявок» на стороне, например, между проектами?

4) Как владелец продукта, я никогда не отдам ключевой продукт на аутсорс

Да, по сути все IT конторы раньше так работали — есть команда на зарплате, берутся проекты на фикс. стоимость. По сути — команды небыло — в основньм один человек на один проект, изредко кучкавались из «свободных» на большой проект. Если проект не могли взять, отдавали коллегам (за коммисию, конечно). Думаете, у вас выйдет по другому?

1) Разные проекты, делаются разным колличеством людей. Есть даже такое понятие — оптимальное колличество работников на проекте. Что будет делать часть вашей команды мечты при простое?
Это если команда большая. А если агильный тим из 10 человек максимум то будут делать 8 или 10 человек — не так уж важно. Сделают быстрее.
2) Зарабатывает деньги тот, кто несёт ответственность. Кто в команде мечты будет попадать на деньги из-за программиста Васи, который заболел?
Для этого и нужна контора, в которой будет работать «команда мечты». В любых компаниях этот вопрос согласовывается с клиентом (отпуска, больничные и т.д.).
3) Выплывает из первых двух — как вы будете удерживать участников от внезапных «халявок» на стороне, например, между проектами?
А зачем удерживать? Успевает человек два проекта делать — так вперед.
4) Как владелец продукта, я никогда не отдам ключевой продукт на аутсорс
Какой «ключевой продукт»? И зачем именно «ключевой»? В аутсорс отдают массу fixed price проектов. От сайтов-визиток до больших веб-магазинов.
Да, по сути все IT конторы раньше так работали — есть команда на зарплате, берутся проекты на фикс. стоимость. По сути — команды небыло — в основньм один человек на один проект, изредко кучкавались из «свободных» на большой проект. Если проект не могли взять, отдавали коллегам (за коммисию, конечно). Думаете, у вас выйдет по другому?
Думаю и сейчас так работают. Зачем по-другому? Просто вместо «набрать новую команду из свободных и новых» конторе проще взять готовую проверенную команду.
Еще раз: я не предлагаю работать самим или открывать свою контору. Все то же самое, но переходить всей командой в другую контору или на другой проект в той же конторе. Не позволить HRрам «раздерибанить» команду что бы позатыкать вакансии.
агильный тим из 10 человек
Это уже явный перебор. Для Agile хорошо иметь человек 6-7. И самое главное. Agile не очень хорош в долгосрочном планировании, при фиксированном ТЗ и стоимости.

чем больше человек — тем больше накладки на общение. Да и не все задачи можно распаралелить. Лучше 8 человек вместо 10, чем наоборот. Так что ваш подход уменьшает вашу конкурентоспособность.

Для этого и нужна контора, в которой будет работать «команда мечты». В любых компаниях этот вопрос согласовывается с клиентом (отпуска, больничные и т.д.).
т.е. Вы хотите «нанимать» контору, которая будет за вас нести ответственность? Вы помните что такое fixed cost? Проект должен быть сделан через 5 месяцев за 50000$. Кто там у вас и когда болел — заказчика слабо вонует. Отпуска и больничные возможны только при почасовой оплате.
А зачем удерживать? Успевает человек два проекта делать — так вперед.
Проблема в том, «ходить на сторону» люди начинают во время простоев. И когда они Вам резко понадобятся — оказывается, что у них есть свой проект со сроками, который тоже надо сдавать. Так как за «свой» проект, каждый отвечает персонально, то скорее всего забьют на коллективный.

Если будете делать свой проект — НИКОГДА не отдавайте ключевые вещи на аутсорс. Представте, что будет, когда вы разорвёте с ними отношения.

Все то же самое, но переходить всей командой в другую контору или на другой проект в той же конторе.
Я вам уже пару раз написал, почему это не реально. Впрочем, Вы просто пересоритесь, при переходе в другую компанию — ведь Васе предложат больше в Giklum-e, а Пете в ClobalLogic

Agile с fixed price + fixed time — это нереальный экстрим. Нужно иметь хотя бы двойной запас по времени — ну, или огромную экспертизу как в предметной области, так и в технологии, чтобы оценить все риски корректно.

Я думаю методика разработки (Agile или нет) мало связанна с моделью оплаты. Если взять fixed all (price, time, scope) проект то риск в любом случае огромный. И даже CMMI или RUP его не сильно уменьшат (только добавят работы).
А вот если что-то не fixed — то тут уже Agile и постоянная коммуникация с клиентом очень помогут. В приведенном примере (fixed price + fixed time) так обязательно. Потому что можно будет сделать 50% изначально задуманного + 20% придуманных изменений и клиент все равно останется доволен. А оставшиеся 30% + еще 50% придуманных клиентом «по ходу» фичеров дадут старт следующему контракту.

Не в команде счастье. Я вижу вам не достает общения, чаще встречайтесь со своими настоящими друзьями, а не коллгами.

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

ЗЫ:
Это комментарий к посту Yegor Chumakov ниже . Промахнулся кнопкой.

Конечно, хорошо когда коллеги=друзья. Но рассчитывать на это не стоит. Более того, дружба может мешать нормальным рабочим отношениям (читай — ради заработка денег).

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

Более того, дружба может мешать нормальным рабочим отношениям (читай — ради заработка денег).
На моём опыте — она куда больше помогает, чем мешает.
А вот отношение «мне пофигу» или еще худшее (aka неприязнь) — влияют крайне негавтивно.
К примеру, мне приходилось содействовать увольнению хороших ребят (хороших как товарищи) по причине недостаточной квалификации.
Такое бывает не редко, а что тут не так? Если человек не подходит на позицию и/или не может делать работу с необходимым качеством, о чём тут вообще говорить?
Да, неприятно, но это бизнесс, а не посиделки с пивом.
Любой номральный человек это понимает, и ни один профессионал не держит проф. не пригодных сотрудников только потому что «они хорошие ребята».

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

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

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

Если Вы реально дружите с сотрудником
... то будете дружить с ним и после того, как он уйдет.
А на его вместо вполне может прийти человек, с которым вы тоже найдете общий язык, как, видимо, у ТС-а и было ни раз.
Но, видимо, продолжать дружить вне работы с людьми не получалось. Тут возникает вопрос, дружили-ли вообще, — или ТС относился к обычным рабочим отношениям как к дружбе?
А это совсем другая история, которая не имеет ничего общего к работе и тому что люди её переодически меняют.

Ну тут кагбы «дружба» между коллегами программистами, а не программистом и менеджером.

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

p.s. Странно обьяснять такие вещи такому бывалому и взрослому дядьке.

Не в команде счастье. Я вижу вам не достает общения, чаще встречайтесь со своими настоящими друзьями, а не коллгами.

А почему это должны быть разные люди??

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

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі