Беседа о вашей работе

[ax_mct]

Цитата:

Сообщение от trud

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

https://www.theverge.com/22807858/ti...ecoder-podcast

по поводу что где-то зп больше, это из разряда у соседа корова толще, мне вот тут недавно жаловался разработчик C++, что есть предел зарплат и он гораздо ниже чем в ERP, попросил посоветовать курсы по системе

Как минимум, этому разработчик C++ нужен карьерный коучинг.
Именно карьерный, а не бизнес коучинг.

А девушка действительно молодец. Только она из другого материала чем данный разработчик C++.

https://hh.ru/search/vacancy?text=C%...archLine=false

826 вакансий «C/C++ разработчик»
от 80 000 руб. 253
от 165 000 руб. 173
от 250 000 руб. 91
от 330 000 руб. 31
от 415 000 руб. 14

https://hh.ru/search/vacancy?cluster...m=suggest_post

71 вакансия «Ax разработчик»
от 145 000 руб. 4
от 170 000 руб. 3
от 195 000 руб. 2
от 220 000 руб. 1

[trud]

Цитата:

Сообщение от Dynamics365Eng

Обажаю такое, когда в споре об общем положении рынка приводят частные случаи. А потом коронку "не нойте". Прям дискуссия 80 левел. Нечего даже добавить.

Вы же сами начали про зарплаты в 500тыс в Java, C#
Но прежде чем смотреть в 500тыс, можно посмотреть требования к джунам за условные 50тыс. Как правило это будет знание основных технологий, умение написать какую-то програмку покрытую авто-тестами. Т.е. в мире АХ человек который умеет это делать работает на позиции архитектора . Пруф - http://kashperuk.blogspot.com/2019/0...test-tips.html
Ну т.е. из моего общения с коллегами из смежных областей - зарплаты в целом одинаковы, но порядок требуемых знаний для программиста АХ гораздо ниже(ибо ниже конкуренция), это плюс. но рынок не такой большой(это минус)
Вот еще в тему поста, site reliability engineer 54 вакансии в Москве
«Еще остается 4–5 часов на игры»: айтишник рассказал, как совмещает сразу 5 фултайм-работ

[GEP442]

Цитата:

Сообщение от trud

Вы же сами начали про зарплаты в 500тыс в Java, C#

Я бы не сказал что такие зарплаты сейчас уже какой-то частный случай, у меня на одном контракте 350 сейчас, при этом это не Java

А если подходить с позицией требований, то, экстраполируя, тик-токерша должна быть семи пядей во лбу, а по факту это всего лишь Excel

Но я согласен, что требования для python / Java / C#-разработчиков значительно выше для разработчиков AX

[Dynamics365Eng]

Цитата:

Сообщение от trud

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

Так как с вашими коллегами я не общаюсь, для меня все таки источником данных остается hh.ru

"Разработка Java"
от 115 000 руб. 752
от 230 000 руб. 537
от 350 000 руб. 234
от 465 000 руб. 63
от 580 000 руб. 20

Выше кинули по аксапте.

[ax_mct]

Цитата:

Сообщение от trud

Но прежде чем смотреть в 500тыс, можно посмотреть требования к джунам за условные 50тыс. Как правило это будет знание основных технологий, умение написать какую-то програмку покрытую авто-тестами.

Т.е. в мире АХ человек который умеет это делать работает на позиции архитектора

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

Цитата:

Сообщение от GEP442

Но я согласен, что требования для python / Java / C#-разработчиков значительно выше для разработчиков AX

Вот типичная позиция архитектора в AX/365.

https://careers.ibm.com/job/13701497..._CareerWebSite

Цитата:

You will lead the technical delivery of D365FO for the client projects
...
mix of consultative skills, business knowledge, and technical expertise to effectively integrate packaged technology into our clients’ business environment and achieve business results.

Уровень скорее руководителя департамента или бизнес-партнера.
Технический куратор отвечающий за бизнес-проекты.
Один из 2-3-4 что тянут/толкают данное направление бизнеса.

Вот аналогичная позиция Application Architect: Java & Web Technologies
https://careers.ibm.com/job/14334401..._CareerWebSite

Цитата:

You will define the scope and vision for projects that deliver customized solutions using your knowledge of Cloud & Micro Services platforms. You are a technical leader, serving as a liaison among business team, developers and project stakeholders.

А если возьмем Java Architect вне продажи IBM, а просто в продуктовой команде, то обнаружим что это Team Lead команды из 6 человек, спокойно спящий по ночам, и думающий об уже родных шаблонах проектирования во фреймворке которому уже больше 10 лет.

Если сравнивать уровнем ниже, то senior developer AX/D365FO по весу и обьему знаний и навыков не уступает весовой категории senior Java developer. Они просто разные.

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

Не сложнее Javа, и не требует больше.

Но тут вопрос кому что больше подходит. Уклон в техническую сторону или антитехническую.

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

[GEP442]

Я говорил про требования к джунам и миддлам

[pitersky]

Цитата:

Сообщение от ax_mct

71 вакансия «Ax разработчик»
от 145 000 руб. 4
от 170 000 руб. 3
от 195 000 руб. 2
от 220 000 руб. 1

обратите внимание, что только для 10% (7 из 71) вакансий по аксапте указана зп. думаю, что реальное количество вакансий с зп 220+ много больше одной

[GEP442]

Цитата:

Сообщение от ax_mct

Там где они пишут авто-тесты для куска кода который может никогда не быть в продакшн

Сейчас код без покрытия юнит-тестами скорее всего просто не пройдёт CI / CD и не будет выпущен в прод, а в конце месяца вам понизят рейтинг аудита с AA до B, как у меня сейчас на одном проекте.

Цитата:

Сообщение от ax_mct

мы делаем самостоятельное тестирование от начала и до конца.

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

Цитата:

Сообщение от ax_mct

С данными, настройками, пониманием и кода, и данных, и бизнес-процессов.

Ну так я в рамках хранилищ данных также касаюсь и данных и бизнес-процессов и настроек разных бизнес-систем

А что юнит-тесты это какая-то магия?

[ax_mct]

Цитата:

Но я согласен, что требования для python / Java / C#-разработчиков значительно выше для разработчиков AX

Цитата:

Сообщение от GEP442

Я говорил про требования к джунам и миддлам

Прошу прощения. Справедливое замечание.

Но если честно не вижу этой высоты для толкового и грамотного
студента с точки зрения технических требований.

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

Младший программист (AX)
от 30 000 до 40 000 руб. на руки

https://hh.ru/vacancy/50042171?from=...cy_search_list

Цитата:

Требования:

Высшее образование;
Желание развиваться в области ERP систем;
Знание одного из ООП языков программирования, опыт работы будет плюсом.
Знание SQL, желателен опыт работы с базами данных;

Программист Java/Kotlin (junior)
от 25 000 до 40 000 руб. на руки

Цитата:

Требования:

Высшее техническое образование (студент последнего курса)

Хорошее знание JAVA или Kotlin и опыт объектно-ориентированного программирования.

Знание теории баз данных и хорошее знание SQL

[ax_mct]

Цитата:

Сообщение от pitersky

обратите внимание, что только для 10% (7 из 71) вакансий по аксапте указана зп. думаю, что реальное количество вакансий с зп 220+ много больше одной

Вот к примеру
Разработчик Microsoft Dynamics AX 2012
з/п не указана
Марвел, ГК

https://hh.ru/vacancy/50536383?from=...cy_search_list

При этом в самой компании Марвел следующие зарплаты у других ведущих ролей

Ведущий специалист по МСФО от 139000 руб.
Главный бухгалтер (работа с маркеплейсами) от 130000 руб.

https://sankt-peterburg.jobfilter.ru...B2%D0%B5%D0%BB

Вангую что зарплата не будет больше 220 тысяч у данной роли.
Уже все стоит, все работает.

[Dynamics365Eng]

Цитата:

Сообщение от pitersky

обратите внимание, что только для 10% (7 из 71) вакансий по аксапте указана зп. думаю, что реальное количество вакансий с зп 220+ много больше одной

Полистал интереса ради. Там про разработчика примерно 30 из 70 (остальное случайно попало). Многие из 30 известные проекты. Многие давно уже ищут (ЦУМ уже легенда просто). Там точно зарплаты не больше 220.

[Dynamics365Eng]

Ложка меда вот. Инглиш правда разговорный
Компания ЕССО
Вилка 250-300К рублей + соц.пакет
Разработчик Axapta senior

[ax_mct]

Цитата:

Сообщение от GEP442

Сейчас код без покрытия юнит-тестами скорее всего просто не пройдёт CI / CD и не будет выпущен в прод, а в конце месяца вам понизят рейтинг аудита с AA до B, как у меня сейчас на одном проекте.


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


Ну так я в рамках хранилищ данных также касаюсь и данных и бизнес-процессов и настроек разных бизнес-систем

А что юнит-тесты это какая-то магия?

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

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

Конечно работа с данными в контексте разрабатываемых решений.
В интеграциях без этого не обойтись. Без знаний к примеру T-SQL и MSSQL Studio и умения администрировать DEV базу данных в процессе своей разработки. Не говоря уже о Azure.

То есть к техническим знаниям программиста AX/365 прибавляем
фунциональные знания
базы данных
DevOps

Это не меряние длины мозга, а про обьем который якобы больше у Java программиста. И конечно же у Data инженера этот обьем даже больше.

Это все к тому что зарплаты совсем не пропорциональны обьему знаний и навыков у типичного программиста AX/365. А лишь про спрос-предложение, и денежные потоки. И про место где этот труд оценивают.

[ax_mct]

Цитата:

Сообщение от Dynamics365Eng

Ложка меда вот. Инглиш правда разговорный
Компания ЕССО
Вилка 250-300К рублей + соц.пакет
Разработчик Axapta senior

Дайте это почитать программисту Java который получает эти 300K просто за чистый кодинг. Он скажет что эта роль как минимум три разных человека и нужен четвертый который будет их координировать. И что такое должно стоить
от 500 тысяч. И с точки зрения IT как индустрии он прав.

Но возможно подобная роль лучше чем 5 одновременных контрактов.
Единственно что удаленно и из Западной страну по визе digital nomad, к примеру.

Цитата:

Разработчик Axapta senior

Глубокое знание языка программирования XPP, внутренних компонентов DAX 2009, 2012 или MS DYNAMICS 365 и языка запросов SQL, особенностей реляционных баз данных и работы.
Желательно понимание основ автоматизации в следующих предметных областях: управление запасами, расчёты с клиентами, расчёты с поставщиками, сводное планирование, WMS контур.
Понимание принципов и опыта интеграции с внешними информационными системами с использованием различных форматов (XML, XLS, веб-сервисы).
Опыт оптимизации производительности MS DAX 2009/2012 или MS DYNAMICS 365, навыки работы с большими объемами данных, работа с высоконагруженными многопользовательскими информационными системами.
Опыт оптимизации кода и запросов, поиска и устранения узких мест в информационных системах; способность понимать чужой программный код.

Прошу прощения за то что меня так много и не уверен что мы не портим чужую тему.

[Dynamics365Eng]

Цитата:

Сообщение от ax_mct

Прошу прощения за то что меня так много и не уверен что мы не портим чужую тему.

Да. Я тоже что то разошелся. Речь про потолок зарплат зашла. И что то увлеклись.
Может автор попросит выделить тему и вернемся к хорошим мотивирующим постам про то, как пробить этот самый потолок.

[axtalk]

Цитата:

Сообщение от ax_mct

Прошу прощения за то что меня так много и не уверен что мы не портим чужую тему.

Я не против, если что))
Работа, вакансии, доход, перспективы и возможности... всё по делу!

[axtalk]

Цитата:

Сообщение от Dynamics365Eng

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

Но одними постами мы потолок не пробьём)
Постами можно лишь подкрепить желание, если оно есть.

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

Таким образом мы сами частично формируем рынок и потолок.

[axtalk]

По отзывам такое абстрактное не очень заходит, но хочется продолжить в поисках (начало тут: Яйцо в чёрном ящике (1 за 10))

Покупатель для нас (программистов/консультантов MS Dynamics AX / D 365 FO) это структура взаимосвязей людей и правил. Эти структуры различны по отношению к нам и меняют свои свойства с введением новых правил или отменой или изменениями старых правил. Эти структуры меняются по отношению к нам от добавления новых людей или уходом или изменением старых людей. «Изменения» людей — это могут быть изменения их отношения к нам или к процессу взаимодействия с нами.

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

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

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

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

Мы такие, как мы есть в обоих случаях, а результаты различны. В первом случае покупатель пришёл за одним конкретным золотым яйцом, во втором покупает чёрный ящик.

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

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

Вот тут тонкий момент: мы меняемся сами в противоречии к себе и затрачиваем ещё больше наших ресурсов безрезультатно или меняем покупателя под себя.

Напомню, что покупатель — это не какой-то конкретный человек или компания. Одна и та же компания может быть одновременно двумя совершенно разными для нас покупателями. Это зависит от положения, которое мы занимаем в этой структуре взаимосвязей и от того, как мы сами видим своё положение.

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

Покупатель для нас чаще всего действительно обезличенная структура, и даже не государство (применительно исключительно к нашей деятельности консультантов и программистов MS Dynamics AX / D 365 FO), как было когда-то. Мы сами создаём себе человечный образ, представляя это, как некие человеческие отношения и проецируя правила и понятия таких отношений по совести на наше взаимодействие с покупателем. И сами создаём себе различные ограничения и загоняем в определенные рамки. Но на самом деле это биржа. Да, там есть реальные люди - звенья структуры, с ними мы и ведем себя по-людски. Но в целом с покупателем другие правила — это не человек и не государство.

С людьми по совести и по человеческим понятиям, с покупателем как со структурой. Тут нет никаких противоречий.

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

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

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

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

Что для вас важнее: человек или структура? Разделяете ли вы эти понятия в повседневной работе? В чьих интересах чаще принимаете решение?

[axtalk]

Это не продолжение истории о двух программистах, а другая история.


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

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

Процесс достаточно подробный и детализированный. Засады чаще всего встречаются по причине того, что никто почти не знает функционал в объёме, достаточном для осознания значимой части задачи.

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

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

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

Это несколько удивляет, даже если не знать ещё более шокирующих подробностей, которые скрыты. Первый программист (тот, который «негатив») работает почти все 8 часов в день на этом проекте и отчитывается за эти 8 часов. А вот второй («позитив») затрачивает 2-4 часа (в среднем 3) своего ежедневного времени на этот проект и при этом отчитывается за те же 8.

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

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

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

3. С внимательностью к деталям изучив процесс, второй программист выяснил, что консультанты формулируют и создают задачи произвольным никем неконтролируемым образом по результату своего общения с пользователем или аналитиком. Пользователь и аналитик тоже могут видеть «свою» задачу, но так как она для программиста, то, по большому счёту, никому из них нет дела до формулировок и смыслов. Но потом консультанта начинают «пинать» его руководители по закрытию в срок некой абстрактной формулировки (придуманной им же). По сути получается, что консультант может сформулировать всё что угодно, протестировать и закрыть всё что угодно, но под прикрытием программиста. Те задачи, которые долго тестируются и постоянно дорабатываются у первого программиста, у второго уже давно закрыты. Никогда не будет негатива от пользователей и аналитиков, а если что, то формулируем новую задачу. Никогда не будет негатива от руководителей, так как все задачи закрываются в срок. Все довольны, консультант застрахован.

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

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

[axtalk]

ice, к нашей прошлой беседе про собеседование и «надбавки за перспективность».

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

Вы ему говорите, что для вашей компании его (кандидата, его опыта и знаний) стоимость составляет 150 тыс. ( в силу специфики работы у вас ), но вы (компания) готовы платить ему «авансом» рыночную стоимость 250 тыс., если он готов показать рост в ближайший год до *2 в своей производительности. Всё верно?

Я правильно понимаю, что разница между 150 и 250 (цифры условны) возникает в силу специфики работы именно в вашей компании? Какие-то особенные процессы и настолько сложный нестандартный функционал, который значительно понижает стоимость для вас программиста относительно рынка.

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

У меня два вопроса:
1. Почему он выберет вашу компанию?
2. Какая у него мотивация будет к ожидаемому вами росту?