Хотелось самим спроектировать схему взаимодействия между отдельными блоками системы. Это интересно
У нас на картинке неточность, исправлю. В основном view и его элементы обновляются через binding, это очень удобно. Но некоторые команды вызывают полное обновление view, которое контролируется engine'ом.
Понятное дело, что вознаграждение должно быть. Дело в деталях:
1) бывает стабильно высокая зарплата,
2) бывает агрессивная система финансовой мотивации (низкая ЗП — высокие бонусы по достижении бизнес результата).
Речь идет о том, что для творчества 1-й подход лучше, чем 2-й.
Возвращаясь к теме оценки «скорости» программиста. На моей практике, сотрудник, который сначала пишет «костыли», а потом дорабатывает изначально неверно написанный код, тратит в сумме больше времени, чем сотрудник, который сразу пишет правильно.
Значит, мне придется Вас разочаровать: оплата каменщика чаще всего именно сдельная. Это действительно приводит к халтуре. Качество формально проверяется, но халтура остается. К счастью, несущие конструкции в крупных зданиях не держатся на кладке.
Угу, есть такое. Поэтому статистику лучше считать по окончании проекта (ну или хотя бы за длительный интервал времени, чтобы снизить роль стат флуктуаций).
Я не сомневаюсь, что статья для некоторых читателей Хабра очевидна. Ну а теперь попробуйте объяснить то же самое не-программисту. И Вы услышите вопросы: а чем программисты такие особенные? почему все профессии как профессии, а программисты вечно ворчат о своей уникальности? ))) Вот статья о том, как я искал эти аргументы, и почему не так просто их донести.
К вопросу о том, в чем причина разброса в продуктивности — покопался в книге Джоэла Спольски, на 95-й странице нашел абзац:
«Пятнадцатилетний опыт программирования убедил меня в том, что все лучшие программисты способны легко разбираться сразу с несколькими уровнями абстракции. По отношению к программированию это означает, что у них нет проблем с рекурсией… или со сложными алгоритмами… Я пришел к выводу, что понимание указателей — это не квалификация, а способность. „
Кхе… знал бы прикуп — жил бы в Сочи :) Четкого ответа у меня нет. Есть наблюдения. Скорость освоения информации — этот параметр заметен уже через пару месяцев совместной работы. Если параметр высокий — то выход на высокую «продуктивность» в проекте получается довольно быстро. Если же скорость освоения информации низка — то события в проекте и в мире технологий будут происходить быстрее, чем человек подстроится под них… в таком печальном случае, скорее всего, человек неправильно выбрал профессию.
Если говорить о том, как вписались agile методолгии в АйТи сообщество бСССР, то на ум приходит такой пример.
Общался с ПМом, человеком почтенного возраста, который утверждал, что у него в проекте применяется гибкая методология, Scrum. По ходу разговора (который не относился напрямую к методике управления проектов), я все больше понимал, что на Agile его подход ну никак не тянет… в общем, в итоге выяснилось, что по-сути это был вотерфолл. Но! Раз в 2 недели у них проходили собрания, «ретро+демо». В обычной ситуации их назвали бы статус-митингами, но они вот отдали дань времени. Ничего другого от agile они не взяли :(
Тут я с вами полностью соглашусь, частенько бывает фейл.
В своем предыдущем комментарии я хотел сказать, что далеко не во всякой ситуации и не всякому человеку будет интересна доля в бизнесе.
Типичный пример — у человека семья, маленький ребенок и/или ипотека, в общем, потребность в стабильном (пусть и относительно небольшом) доходе. И вот наступили тяжелые для компании времена, впереди маячит нестабильная финансовая ситуация (пусть даже с очень вероятным крупным финансовым успехом в конце) — такому человеку важнее иметь рубль завтра и возможность вернуться к семье после 6 вечера, чем 10 рублей после 2 лет полной выкладки.
Бывает другая ситуация, что молодой специалист хочет роста, причем, амбиции идут куда дальше, чем зарплата senior developer'а. Что ж, такой человек заинтересуется долевым участием в бизнесе.
По моему опыту, 1-я ситуация встречается чаще, чем 2-я. И к чему я это говорю? К тому, что пропагандируемое вами решение: предлагать программистам долю в компании в случае серьезных передряг — может и не сработать.
Тот, кто готов и имеет возможность рискнуть (или как вы говорите — взять на себя ответственность) — тот идет и открывает свою фирму. Я знаю много отличных программистов, ответственных людей, которым очень важно иметь стабильный доход (молодая семья, маленький ребенок, или родители на содержании).
«Хороший» ПМ мог бы выписать человеку, «спасшему» в проекте 100 руб, премию в размере 10 руб., сэкономив в итоге 90 руб. Вопрос в том, интересна ли эта экономия ПМу? Если ему самому будет премия в 10 руб по итогам проекта за эту экономию — то адекватный ПМ выслушает предложения сотрудников, и возьмет на себя риски по реализации этих идей.
Бывает так, что ПМ выглядит как «плохой парень». Может быть, неопытен. Может быть, потому что очень верит в X-теорию. Или молится на теорию научного управления Тейлора, не дочитав ее до конца. Или просто не нашел общий язык с разработчиком — и теперь они грызутся как кошка с собакой. В любом случае, если ваш ПМ — «плохой» — то ходить к нему с предложениями об оптимизации рабочего процесса неэффективно.
Разберитесь, действительно ли перед вами неадекватный ПМ — или вы всего лишь не нашли с ним общий язык. Если нормального разговора ну никак не получается — тогда уже можно переходить на манипуляции: давление, саботаж, жалобы вышестоящему руководству.
И то, что он сэкономит деньги не особо влияет на его заработную плату.
Во-первых, если ПМ выйдет за рамки бюджета, его точно не погладят. А «бунт» в команде (например, в виде увольнений) именно к срыву бюджета и приведет.
Во-вторых, было бы хорошо ввести для ПМа премию по итогам сохранения бюджета. Иначе какая разница ПМу — сэкономить 5% или 15% бюджета? Все равно уложится в бюджет…
ИМХО, если ПМ не заинтересован сохранять бюджет проекта — это реально беда. Тем не менее, в компании чаще всего можно найти человека старше до должности, которого экономия все таки интересует: в пределе, можно дойти до собственника предприятия, его то должны интересовать свои деньги. Другой вопрос, стоит ли игра свеч? Не проще ли найти более адекватного работодателя?
У нас на картинке неточность, исправлю. В основном view и его элементы обновляются через binding, это очень удобно. Но некоторые команды вызывают полное обновление view, которое контролируется engine'ом.
Вообще, речь шла о том, что нубов в команде должно быть поменьше.
1) бывает стабильно высокая зарплата,
2) бывает агрессивная система финансовой мотивации (низкая ЗП — высокие бонусы по достижении бизнес результата).
Речь идет о том, что для творчества 1-й подход лучше, чем 2-й.
А вообще, повышение точности оценки, а также целесообразность получения такой точной оценки — тема для отдельной статьи.
«Пятнадцатилетний опыт программирования убедил меня в том, что все лучшие программисты способны легко разбираться сразу с несколькими уровнями абстракции. По отношению к программированию это означает, что у них нет проблем с рекурсией… или со сложными алгоритмами… Я пришел к выводу, что понимание указателей — это не квалификация, а способность. „
Общался с ПМом, человеком почтенного возраста, который утверждал, что у него в проекте применяется гибкая методология, Scrum. По ходу разговора (который не относился напрямую к методике управления проектов), я все больше понимал, что на Agile его подход ну никак не тянет… в общем, в итоге выяснилось, что по-сути это был вотерфолл. Но! Раз в 2 недели у них проходили собрания, «ретро+демо». В обычной ситуации их назвали бы статус-митингами, но они вот отдали дань времени. Ничего другого от agile они не взяли :(
В своем предыдущем комментарии я хотел сказать, что далеко не во всякой ситуации и не всякому человеку будет интересна доля в бизнесе.
Типичный пример — у человека семья, маленький ребенок и/или ипотека, в общем, потребность в стабильном (пусть и относительно небольшом) доходе. И вот наступили тяжелые для компании времена, впереди маячит нестабильная финансовая ситуация (пусть даже с очень вероятным крупным финансовым успехом в конце) — такому человеку важнее иметь рубль завтра и возможность вернуться к семье после 6 вечера, чем 10 рублей после 2 лет полной выкладки.
Бывает другая ситуация, что молодой специалист хочет роста, причем, амбиции идут куда дальше, чем зарплата senior developer'а. Что ж, такой человек заинтересуется долевым участием в бизнесе.
По моему опыту, 1-я ситуация встречается чаще, чем 2-я. И к чему я это говорю? К тому, что пропагандируемое вами решение: предлагать программистам долю в компании в случае серьезных передряг — может и не сработать.
Бывает так, что ПМ выглядит как «плохой парень». Может быть, неопытен. Может быть, потому что очень верит в X-теорию. Или молится на теорию научного управления Тейлора, не дочитав ее до конца. Или просто не нашел общий язык с разработчиком — и теперь они грызутся как кошка с собакой. В любом случае, если ваш ПМ — «плохой» — то ходить к нему с предложениями об оптимизации рабочего процесса неэффективно.
Разберитесь, действительно ли перед вами неадекватный ПМ — или вы всего лишь не нашли с ним общий язык. Если нормального разговора ну никак не получается — тогда уже можно переходить на манипуляции: давление, саботаж, жалобы вышестоящему руководству.
Во-первых, если ПМ выйдет за рамки бюджета, его точно не погладят. А «бунт» в команде (например, в виде увольнений) именно к срыву бюджета и приведет.
Во-вторых, было бы хорошо ввести для ПМа премию по итогам сохранения бюджета. Иначе какая разница ПМу — сэкономить 5% или 15% бюджета? Все равно уложится в бюджет…