Правильные ответы:
1) Не ваше дело.
2) Не ваше дело.
3) Не ваше дело.
4) Не ваше дело.
5) Если компания будет меня устраивать, а я компанию — много.
6) Не вопрос.
7) Можете не перезванивать.
Не по премиям и зарплатам, а по KPI. Да, это общая оценка, но вот принципы, на которых она строится — вполне конкретны. И показатели вполне объективны (в моем случае, это на 80% RoA, CuS, ClS). Если знаете другой способ оценить эффективность — пишите статью, с удовольствием ее прочитаю, и обещаю хорошо подумать (без какого-либо сарказма). Я, к сожалению, таких способов не знаю.
А мне глубоко фиолетово, что там думает аутстафер, тем более который уже ушел. Мне глубоко пофигу как он пытается меня вокруг чего-то вертеть. Мне сильно по барабану на Ваше мнение относительно эффективности разработчика при микроменеджменте и при вовлеченности. Мне искренне начихать на ваши сомнения относительно моей должности, и на то, на чем они основаны.
А вот размер моей годовой премии меня очень даже интересует. И зависит она исключительно от моего личного KPI, который, во многом, зависит от KPI моего подразделения. И если судить именно по ней — я просто сама деловитость и эффективность.
С уважением, директор департамента развития банковских технологий, ПАО "............"
Слишком. В последнее время трачу на ТЗ и прочую документацию (за исключением пользовательских мануалов, ими занимаются отдельные люди) до 6 часов в день. В основном, это формализация требований бизнеса (перевод с русского на программерский). Для работы с аутстаферами удалось выделить отдельного человека, иначе вообще кроме бумажек ничего бы не видел. Оставшиеся 2 часа — либо ревью кода, либо живое общение с бизнесом/исполнителями. Кодить времени почти уже нет.
UPD: работа с таск- и баг-трекерами в это время тоже входит.
Вы все исключительно верно написали. Оплата аутстаферов — как правило посуточная. Моя задача — выжать его за эти сутки по максимуму. Вы думаете, я оставлю ему время на эксперименты с фреймворками? Я оцениваю время на задачу, согласовываю с ним — все, арбайтен. Задачи для аутстафера в принципе не должны превышать 4 часа.
Если менеджер не умеет слышать разработку — это действительно очень печально. Отсутствие архитектуры — еще более печально. Тут я Вас прекрасно понимаю, поскольку у самого вполне себе программерский бэкграунд, и через все это неоднократно проходил. Но разговор изначально не о том. В моем случае ТЗ пишу я САМ. А не менеджер компании аутсорсера ДЛЯ МЕНЯ. Я знаю, на сколько все мои системы и модули завернуты в абстракции, где какие имеют коннекторы и так далее. Я знаю архитектуру, а не менеджер. Именно поэтому, мое ТЗ не оставляет шансов менеджеру-аутсорсеру всунуть мне какашку, которую вы описываете, и которая у меня просто не будет работать, а если и будет — за дополнительные деньги. Я ее просто не приму, не заплачу за нее, и даже не буду париться, выслушивая какой я нехороший, поскольку они вот старались, сроки соблюдали и так далее…
Требования — это то, как надо писать код, чтобы его можно было легко читать, поддерживать, рефакторить, переиспользовать. В основном — это выжимка из PSR`ов и "лучших принципов", типа DRY, KISS, SOLID и тд, а также указания где их использовать нельзя в принципе (да, и так бывает). Плюс, мой собственный бред, на тему как надо (будем считать так). Если что — про кривые вложенные циклы там даже написано )))) Всего, в моем случае, это 3 документа на 142 страницы А4 в сумме. Последний раз изменения в эти документы вносились вчера, до этого 2 месяца правок небыло. Выполнение этих требований обязательно для прохождения Code Review. Не выполнение — достаточный, но не необходимый (есть еще ТЗ) аргумент для деклайна PR. ТЗ — требования необходимые для автоматизации конкретного бизнес-процесса, либо требования к ИС в целом. Невыполнение ТЗ — также деклайн. Если разработчик выполнил и требования и ТЗ — его код будет принят и оплачен, вне зависимости от его отношения к продукту.
Простите, я не знаю как в крупных проектах, я знаю как у меня (на текущий момент — банковская группа). Если те проекты не умеют работать с аутсорсом и аутстафом — пусть не работают. Я — умею. Такой вывод делаю на основании того, что получаю от этого вполне ощутимую прибыль. Именно потому что ТРЕБУЮ делать строго по ТЗ. Если ТЗ написано криво — это только моя ответственность. Если оно написано криво — я получу за те же деньги кучу БЕСПОЛЕЗНОГО кода. Полезный код — это код который легко поддерживается, рефакторится, переиспользуется, автоматизирует бизнес-процессы. Это те требования, которые я к нему предъявляю (точнее результат тех требований). С чего бы он должен приводить к большИм затратам, ну или как минимум, к затратам бОльшим чем код, написанный за большое количество времени? Как тут время вообще коррелируется с качеством? Вы искренне считаете, что "Hello, world!" на который потратили 2 недели будет сильно качественнее чем тот, который смогли написать за 2 минуты? А вам не приходит в голову, что разработчику из вашего примера ТЗ и было написано потому что шаг влево/вправо — и все упадет? Нахрен мне его самодеятельность не нужна в этом случае, я не хочу чтобы что-то падало. От этого страдает бизнес.
Хочу посмотреть на проблему с другой стороны "экрана". То есть со стороны человека, который заказывает музыку.
Для начала, давайте определимся с терминологией. Аутстаф — сотрудник, работающий в другой компании, но предоставленный мне для реализации моих задач. Проходит техническое собеседование для оценки профессиональных навыков. Подчиняется внутреннему распорядку моей компании, делает то, что я скажу, в рамках должностных обязанностей и инструкций. Плачу я за его жопочасы. Аутсорс — сотрудник сторонней компании, которого я в жизни могу ни разу не увидеть. Мне вообще пофигу кто он, где и как работает, сколько получает. Деньги я плачу его работодателю за результат его работы. Сотрудник — сотрудник, который работает в моей компании, ну тут вроде как все понятно.
Моя первоочередная задача — получить от сотрудничества максимальную выгоду.
Если мы говорим об аутстафе — мне выгодно чтобы он писал. Мне не выгодно, чтобы он отвлекался на вникание в продукт. Мне нужно получить от него максимум полезного кода за минимальный промежуток времени. Для этого он получает требования, следование которым делают код полезным, а оценку полезности прозрачной и объективной. Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования. Он сдает код на ревью ровно так же как и мои штатные сотрудники, по результатам которого оценивается соответствие кода ТЗ и тем самым требованиям. Выполнил — молодец. Вот тебе следующее ТЗ. Нет — переделать. Снова не справился — прошу его работодателя прислать нового. Все строго по джире, все строго по часам. Я не хочу платить деньги за образование таких сотрудников. Я не хочу платить деньги за их кофебрейки, разглядывание котиков в интернетиках и их присутствие на митапах, где они абсолютно не нужны (ну понятно, все в разумных пределах, я не надсмотрщик над рабами). Я не хочу платить за вникание. Только бизнес, только код, ничего личного.
Если мы говорим об аутсорсе — все сильно проще. Есть то же самое ТЗ. Как правило, чуть более сжатое, поскольку описывает не одну задачу на несколько часиков, а требования к значительной части продукта, либо к продукту в целом. Да, я закладываю время на обсуждения и уточнения этого ТЗ с второй стороной. Я закладываю в бюждет чуть больше чем изначально в договоре (НИКОГДА в моей практике, финальная стоимость не была равна стоимости по договору). Я отдаю ровно те же самые требования, которые получил аутстафер. Я получаю результат. Я оцениваю результат. Я плачу за результат, если он меня устроил. Все. Больше меня ничего не интересует. В продукт должен вникнуть менеджер, с которым я работаю. Или не должен понимать продукт, но должен правильно понимать ТЗ. Будут ли вникать в него программисты той фирмы — мне не важно.
Мой сотрудник: должен знать все те требования к коду наизусть. Еще лучше — интуитивно понимать их. Должен понимать архитектуру, ожидания от продукта и его философию. Должен, потому что у меня просто не хватит времени писать для всех них подробные ТЗ как для аутстаферов. Должен учиться, развиваться, думать. И я готов за это платить, мне это выгодно, поскольку такие сотрудники экономят и мое время, и бюджеты компании, и вообще — главная ценность софтверной фирмы.
Так что все, что описано автором — вполне себе так и должно быть. И не приплетайте сюда говнокод и рассуждения, кто лучше пишет. Это ровным счетом никак не зависит от того, в какой компании работает человек. Это зависит исключительно от его личных качеств и навыков, а также от умения читать требования заказчика, как внутреннего, так и внешнего, и выполнять их. Если заказчик таких требований не предоставил — его проблемы.
И да, фреймворки и кододрочерство тоже к этой проблеме не имеют никакого отношения. Все должно быть строго регламентировано в рамках ТЗ. Аутсорс или аутстаф, меняющие по желанию стек продукта — нонсенс или идиотизм заказчика.
Как заказчик-продуктовик, работающий с аутстафом последние эдак лет 10, могу со всей ответственностью сказать: говнокод вы получаете не в том случае если прогеру пофиг на продукт, а в том, если вы не дали ему требования, которые необходимо выполнять, чтобы не получилось говнокода. И абсолютно индифферентно, продуктовик или аутстафер этот код будут писать.
Тут, к сожалению, вопрос к компетентности разработчика в целом. Если человек не умеет, его нужно либо учить, либо менять. С аутстафером даже проще в этом плане — не компетентен, до свидания, пришлите другого. Нет всяких ТК РФ и прочего, это не ваш сотрудник. В остальном — ревью кода проводится одинаковое что для «своих» продуктовиков, что для «чужих» аутстаферов, говнокод заворачивается в любом случае.
Писал чуть выше, напишу еще раз: если аутстаф-разработчику приходится вникать в бизнес-процессы компании — компания не выстроила свои бизнес-процессы. В итоге, будет как вы пишете: говнокод и полная неудовлетворенность заказчиком/заказчика. Если компания четко знает что делать внутри, а что можно и нужно отдать на аутсорс/аутстаф/фриланс — все будут довольны. Не аутстафер должен формализовать процессы компании, а компания должна их очень четко описать. Исключения — аудит и оптимизация процессов, либо внедрения каких-либо CRM, когда приходит специально обученный аутстафер, и все это формализует. Разработчиком он, как правило, не является от слова совсем.
А причем тут вообще фанаты фреймо- и кододрочерства? Я, как лид, ПМ, ПО и тот человек, который отвечает за продукт перед бизнесом (и фреймо-кододрочер по совместительству) должен прекрасно понимать, когда можно менять инструментарий, когда это сделать категорически нужно, а когда категорически нельзя идти на поводу таких товарищей. Вы взяли на работу людей, которые не в состоянии работать над продуктом, потому что занимаются фигней и исключительно сменой стека — это ваши проблемы. Вы отдали что-то аутстаферу, не написав должным образом ТЗ (в котором должен быть указан стек), Code Style и Code Convenction? Это снова ваши проблемы. Кстати, автор кододрочерами называет именно аутстаферов, а не продуктовиков… И у аутстафера не должно быть НИКАКОЙ точки зрения на продукт. Ему, с точки зрения ПМ`а и ПО`ра, думать вообще вредно.
Вы сейчас путаете теплое с мягким. Давайте посмотрим на это со стороны… Ну хотя бы Product Owner`а — итак, что нам надо: продукт, который будет приносить людям радость, а люди за эту радость будут платить. Желательно получить этот продукт как можно быстрее и как можно дешевле. При этом все задачи на проекте, как правило, делятся на 2 категории: на подумать и на запилить. При этом задачи «на подумать» — это не просто бейн-сторм нон-стоп. Это эксперименты, неудачи, поиски. Для этого хороши именно продуктовые программеры. Задачи на «запилить» — четко регламентированные, хорошо описанные, и, в большинстве случаев, абсолютно тупые. От забора и до обеда. Думать не надо. Нужно просто писать код. Хороший, легко читаемый и легко поддерживаемый код. И вот тут себя галерные рабы покажут гораздо лучше. Поскольку будут и эффективнее и дешевле. В итоге, хороший PO будет совмещать.
Вот именно поэтому, когда я пришел на текущую работу, у меня было обязательное условие — финальное решение о приеме в мой отдел остается за мной. Чтобы никакие HR`ы не лезли своими кривыми лапками (хотя в этом плане повезло, девочки оказались достаточно адекватными чтобы согласиться, а вышестоящее руководство и не спорило) со своими «синергиями» и «токсичностями».
Сеньорам, как правило, достаются куда как большие по объему и сложности «участки» кода, в следствии чего мид может потратить на ревью больше времени чем сеньор потратил на его написание. Без ревью и закрытия всех дискасов реквест не может быть принят. Так что просто оптимизировали время принятия ПР на основе компетенций и исходя из предшествующего негативного опыта. А по поводу копания миддлом в коде сеньора — да, полезно. И это делается в рамках ретроспектив. Но ни как не в рамках ПР. Скажу больше, были случаи, когда миддлы, по результатам ретроспективы, предлагали куда как более красивые решения, нежели сделал сеньор. Но это уже совсем другая история (отдельная задача по тех. долгу в бэклог и, как следствие, отдельный ПР со всеми вытекающими).
Это не вопрос качества ревью, это вопрос качества процессов в компании. 80% разрабов делают ревью — это маразм. Ревью должны делать 3-4 человека. 2 берутся случайным образом из разработчиков того же уровня или выше (мид за сеньором не ревьюит, это принципиально), один — руководитель группы и один — тех.лид (резолвит реквест). И при этом, если кто-либо реквест заворачивает, он должен популярно обосновать причину. Таких причин может быть вполне конкретное количество: нарушение архитектуры, некорректная реализация бизнес-логики/алгоритма, нарушение Code Conventions (обычно указывается документ и номер пункта, условия которого были нарушены). За «Вась, он нормально сделал, забей» человек останется без премии, как минимум.
Правильные ответы:
1) Не ваше дело.
2) Не ваше дело.
3) Не ваше дело.
4) Не ваше дело.
5) Если компания будет меня устраивать, а я компанию — много.
6) Не вопрос.
7) Можете не перезванивать.
В том-то и дело, что плюсик в языке с динамической типизацией был бы абсолютно неуместен.
Не по премиям и зарплатам, а по KPI. Да, это общая оценка, но вот принципы, на которых она строится — вполне конкретны. И показатели вполне объективны (в моем случае, это на 80% RoA, CuS, ClS). Если знаете другой способ оценить эффективность — пишите статью, с удовольствием ее прочитаю, и обещаю хорошо подумать (без какого-либо сарказма). Я, к сожалению, таких способов не знаю.
А мне глубоко фиолетово, что там думает аутстафер, тем более который уже ушел. Мне глубоко пофигу как он пытается меня вокруг чего-то вертеть. Мне сильно по барабану на Ваше мнение относительно эффективности разработчика при микроменеджменте и при вовлеченности. Мне искренне начихать на ваши сомнения относительно моей должности, и на то, на чем они основаны.
А вот размер моей годовой премии меня очень даже интересует. И зависит она исключительно от моего личного KPI, который, во многом, зависит от KPI моего подразделения. И если судить именно по ней — я просто сама деловитость и эффективность.
С уважением, директор департамента развития банковских технологий, ПАО "............"
Слишком. В последнее время трачу на ТЗ и прочую документацию (за исключением пользовательских мануалов, ими занимаются отдельные люди) до 6 часов в день. В основном, это формализация требований бизнеса (перевод с русского на программерский). Для работы с аутстаферами удалось выделить отдельного человека, иначе вообще кроме бумажек ничего бы не видел. Оставшиеся 2 часа — либо ревью кода, либо живое общение с бизнесом/исполнителями. Кодить времени почти уже нет.
UPD: работа с таск- и баг-трекерами в это время тоже входит.
Вы все исключительно верно написали. Оплата аутстаферов — как правило посуточная. Моя задача — выжать его за эти сутки по максимуму. Вы думаете, я оставлю ему время на эксперименты с фреймворками? Я оцениваю время на задачу, согласовываю с ним — все, арбайтен. Задачи для аутстафера в принципе не должны превышать 4 часа.
Если менеджер не умеет слышать разработку — это действительно очень печально. Отсутствие архитектуры — еще более печально. Тут я Вас прекрасно понимаю, поскольку у самого вполне себе программерский бэкграунд, и через все это неоднократно проходил. Но разговор изначально не о том. В моем случае ТЗ пишу я САМ. А не менеджер компании аутсорсера ДЛЯ МЕНЯ. Я знаю, на сколько все мои системы и модули завернуты в абстракции, где какие имеют коннекторы и так далее. Я знаю архитектуру, а не менеджер. Именно поэтому, мое ТЗ не оставляет шансов менеджеру-аутсорсеру всунуть мне какашку, которую вы описываете, и которая у меня просто не будет работать, а если и будет — за дополнительные деньги. Я ее просто не приму, не заплачу за нее, и даже не буду париться, выслушивая какой я нехороший, поскольку они вот старались, сроки соблюдали и так далее…
Требования — это то, как надо писать код, чтобы его можно было легко читать, поддерживать, рефакторить, переиспользовать. В основном — это выжимка из PSR`ов и "лучших принципов", типа DRY, KISS, SOLID и тд, а также указания где их использовать нельзя в принципе (да, и так бывает). Плюс, мой собственный бред, на тему как надо (будем считать так). Если что — про кривые вложенные циклы там даже написано )))) Всего, в моем случае, это 3 документа на 142 страницы А4 в сумме. Последний раз изменения в эти документы вносились вчера, до этого 2 месяца правок небыло. Выполнение этих требований обязательно для прохождения Code Review. Не выполнение — достаточный, но не необходимый (есть еще ТЗ) аргумент для деклайна PR. ТЗ — требования необходимые для автоматизации конкретного бизнес-процесса, либо требования к ИС в целом. Невыполнение ТЗ — также деклайн. Если разработчик выполнил и требования и ТЗ — его код будет принят и оплачен, вне зависимости от его отношения к продукту.
Простите, я не знаю как в крупных проектах, я знаю как у меня (на текущий момент — банковская группа). Если те проекты не умеют работать с аутсорсом и аутстафом — пусть не работают. Я — умею. Такой вывод делаю на основании того, что получаю от этого вполне ощутимую прибыль. Именно потому что ТРЕБУЮ делать строго по ТЗ. Если ТЗ написано криво — это только моя ответственность. Если оно написано криво — я получу за те же деньги кучу БЕСПОЛЕЗНОГО кода. Полезный код — это код который легко поддерживается, рефакторится, переиспользуется, автоматизирует бизнес-процессы. Это те требования, которые я к нему предъявляю (точнее результат тех требований). С чего бы он должен приводить к большИм затратам, ну или как минимум, к затратам бОльшим чем код, написанный за большое количество времени? Как тут время вообще коррелируется с качеством? Вы искренне считаете, что "Hello, world!" на который потратили 2 недели будет сильно качественнее чем тот, который смогли написать за 2 минуты? А вам не приходит в голову, что разработчику из вашего примера ТЗ и было написано потому что шаг влево/вправо — и все упадет? Нахрен мне его самодеятельность не нужна в этом случае, я не хочу чтобы что-то падало. От этого страдает бизнес.
Хочу посмотреть на проблему с другой стороны "экрана". То есть со стороны человека, который заказывает музыку.
Для начала, давайте определимся с терминологией. Аутстаф — сотрудник, работающий в другой компании, но предоставленный мне для реализации моих задач. Проходит техническое собеседование для оценки профессиональных навыков. Подчиняется внутреннему распорядку моей компании, делает то, что я скажу, в рамках должностных обязанностей и инструкций. Плачу я за его жопочасы. Аутсорс — сотрудник сторонней компании, которого я в жизни могу ни разу не увидеть. Мне вообще пофигу кто он, где и как работает, сколько получает. Деньги я плачу его работодателю за результат его работы. Сотрудник — сотрудник, который работает в моей компании, ну тут вроде как все понятно.
Моя первоочередная задача — получить от сотрудничества максимальную выгоду.
Если мы говорим об аутстафе — мне выгодно чтобы он писал. Мне не выгодно, чтобы он отвлекался на вникание в продукт. Мне нужно получить от него максимум полезного кода за минимальный промежуток времени. Для этого он получает требования, следование которым делают код полезным, а оценку полезности прозрачной и объективной. Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования. Он сдает код на ревью ровно так же как и мои штатные сотрудники, по результатам которого оценивается соответствие кода ТЗ и тем самым требованиям. Выполнил — молодец. Вот тебе следующее ТЗ. Нет — переделать. Снова не справился — прошу его работодателя прислать нового. Все строго по джире, все строго по часам. Я не хочу платить деньги за образование таких сотрудников. Я не хочу платить деньги за их кофебрейки, разглядывание котиков в интернетиках и их присутствие на митапах, где они абсолютно не нужны (ну понятно, все в разумных пределах, я не надсмотрщик над рабами). Я не хочу платить за вникание. Только бизнес, только код, ничего личного.
Если мы говорим об аутсорсе — все сильно проще. Есть то же самое ТЗ. Как правило, чуть более сжатое, поскольку описывает не одну задачу на несколько часиков, а требования к значительной части продукта, либо к продукту в целом. Да, я закладываю время на обсуждения и уточнения этого ТЗ с второй стороной. Я закладываю в бюждет чуть больше чем изначально в договоре (НИКОГДА в моей практике, финальная стоимость не была равна стоимости по договору). Я отдаю ровно те же самые требования, которые получил аутстафер. Я получаю результат. Я оцениваю результат. Я плачу за результат, если он меня устроил. Все. Больше меня ничего не интересует. В продукт должен вникнуть менеджер, с которым я работаю. Или не должен понимать продукт, но должен правильно понимать ТЗ. Будут ли вникать в него программисты той фирмы — мне не важно.
Мой сотрудник: должен знать все те требования к коду наизусть. Еще лучше — интуитивно понимать их. Должен понимать архитектуру, ожидания от продукта и его философию. Должен, потому что у меня просто не хватит времени писать для всех них подробные ТЗ как для аутстаферов. Должен учиться, развиваться, думать. И я готов за это платить, мне это выгодно, поскольку такие сотрудники экономят и мое время, и бюджеты компании, и вообще — главная ценность софтверной фирмы.
Так что все, что описано автором — вполне себе так и должно быть. И не приплетайте сюда говнокод и рассуждения, кто лучше пишет. Это ровным счетом никак не зависит от того, в какой компании работает человек. Это зависит исключительно от его личных качеств и навыков, а также от умения читать требования заказчика, как внутреннего, так и внешнего, и выполнять их. Если заказчик таких требований не предоставил — его проблемы.
И да, фреймворки и кододрочерство тоже к этой проблеме не имеют никакого отношения. Все должно быть строго регламентировано в рамках ТЗ. Аутсорс или аутстаф, меняющие по желанию стек продукта — нонсенс или идиотизм заказчика.