Комментарии 59
Мне кажется ит-спецы совсем зажрались, уже каждый джуниор пишет такие тексты, ждет, что работа это когда он сидит вконтактике начальство ему постоянно докладывает о своих планах на ближайшие 6 лет, а если проект фейлиться то это начальник мудак, я же говорил что helloWorld меньше чем за 3 недели не написать(я же еще и вконтактике сидеть буду). И да зарплата не меньше 4к$.
И что в этом плохого? В кои-то веки появилась отрасль, где начальник-самодур не может плевать на мнение сотрудников, потому что хороший сотрудник — это редкость. И никто бы не платил джуниору больших денег, если бы была такая возможность, но т.к. людей на рынке труда мало, то приходится платить за право иметь сотрудника (пусть даже и неопытного).
И еще: если людям платят такую зарплату — значит результаты их работы приносят гораздо больше, иначе её было бы не с чего платить.
И еще: если людям платят такую зарплату — значит результаты их работы приносят гораздо больше, иначе её было бы не с чего платить.
Тут еще важно не поменять началника-самодура на сотрудника-самодура. А то из вашего текста не совсем понятно, считаете ли вы нормальным плевать на мнение начальника или нет.
Честно говоря, я вообще рассуждал вне контекста «нормально/ненормально», я считаю, что все люди должны относиться друг к другу уважительно, не обращая внимания на должность и ситуацию на рынке труда.
Просто текущая ситуация на рынке IT располагает к тому, что работник может вести себя так, как захочет, но это очень недальновидно — во-первых, никогда не знаешь, когда еще придется встретиться с человеком и при каких обстоятельствах, а во-вторых, сегодня ты джуниор, а завтра — менеджер проекта. Надо всегда поддерживать культуру взаимоотношений и учета интересов обеих сторон.
Просто текущая ситуация на рынке IT располагает к тому, что работник может вести себя так, как захочет, но это очень недальновидно — во-первых, никогда не знаешь, когда еще придется встретиться с человеком и при каких обстоятельствах, а во-вторых, сегодня ты джуниор, а завтра — менеджер проекта. Надо всегда поддерживать культуру взаимоотношений и учета интересов обеих сторон.
Но согласитесь, доля правды в посте есть, особенно это характерно для небольших городов.
Рабовладение закончилось. Мы работаем в условиях рынка. И платить программисту придется столько, сколько его труд на этом рынке стоит.
Как-то, так.
Как-то, так.
Столько, сколько принято платить, а не столько, сколько стоит. Высокие зарплаты в IT в России вызваны глобализацией: они одного порядка с общемировыми. Больше нет ни одной объективной причины, почему средние специалисты в одной конкретной области получают в несколько раз больше, чем средняя зарплата по стране.
В странах с более высокой средней зарплатой относительная «стоимость» программистов ниже, и это здорово.
В странах с более высокой средней зарплатой относительная «стоимость» программистов ниже, и это здорово.
Ну, я думаю, «относительность» стоимости специалиста в IT как раз-таки и не сильно важна, т.к. многи специалисты могут работать удаленно, что означает утечку кадров туда, где больше платят. И если в «других странах» это N, а «здесь» — N-100, то специалист будет вкладывать силы, чтобы найти место удаленщика именно в «других странах». Это создает еще большую нехватку кадров, что заставляет зарплаты сравнивать.
Кстати, смотреть кто-почем можно здесь. (Вдруг не все еще знают)
Странно такое читать, в бюджетировании и продуктивности разработчиков есть вполне серьезные и конкретные процессы регулирования спорных вопросов.
Как, например, при приеме на работу продуктивность и знания разработчика оценивается уполномоченными специалистами компании, после чего существует испытательный срок для валидации KPI работника. В соответствии с этой оценкой сотруднику предлагается заработная плата, отражающая его продуктивность. И если от сотрудника требуют больше чем его оцененная заранее продуктивность, то это вина не сотрудника. Если же можно визуализировать процесс снижения продуктивности, то встает вопрос о компетентности сотрудника и изменении его компенсации. Здесь все честно и нету никакого шантажа или чего-то другого: просто прозрачный процесс регулирования бюджетов.
И напоследок, давайте будем честными: невозможно работать не отрываясь 8 часов в день. Никому, таких людей просто не существует. Будет и вконтактик и разговоры и чай/кофе. Не имеет смысла контролировать сотрудников на тему того что «а открыта ли у вас IDE в данный момент». Потому что все это выльется в то, что IDE будет открыта, но толку от этого не будет. И правда, пора на эту тему уже статьи писать.
Как, например, при приеме на работу продуктивность и знания разработчика оценивается уполномоченными специалистами компании, после чего существует испытательный срок для валидации KPI работника. В соответствии с этой оценкой сотруднику предлагается заработная плата, отражающая его продуктивность. И если от сотрудника требуют больше чем его оцененная заранее продуктивность, то это вина не сотрудника. Если же можно визуализировать процесс снижения продуктивности, то встает вопрос о компетентности сотрудника и изменении его компенсации. Здесь все честно и нету никакого шантажа или чего-то другого: просто прозрачный процесс регулирования бюджетов.
И напоследок, давайте будем честными: невозможно работать не отрываясь 8 часов в день. Никому, таких людей просто не существует. Будет и вконтактик и разговоры и чай/кофе. Не имеет смысла контролировать сотрудников на тему того что «а открыта ли у вас IDE в данный момент». Потому что все это выльется в то, что IDE будет открыта, но толку от этого не будет. И правда, пора на эту тему уже статьи писать.
Поддерживаю. У нас на предприятии специалист по охране труда недавно лекцию читал. С его слов, «оператору ПК» полагается на 1 час работы 10 минут отдыха (причём именно активного, а не просиживания за компом).
>> И напоследок, давайте будем честными: невозможно работать не отрываясь 8 часов в день. Никому, таких людей просто не существует. Будет и вконтактик и разговоры и чай/кофе.
«Работать программистом» это не значит непрерывно втыкать в монитор по 8 часов в день. Был у нас такой нонсенс, начальство решило замерить эффективность программистов-коллег из другого подразделения с помощью секундомера…
Да кстати у меня периодически бывало, что и 8 часов было мало. Если задача интересна, она не отпускает, даже когда ложишься спать.
P.S. не минусую
«Работать программистом» это не значит непрерывно втыкать в монитор по 8 часов в день. Был у нас такой нонсенс, начальство решило замерить эффективность программистов-коллег из другого подразделения с помощью секундомера…
«Спешка» и «усилия» ценятся в программировании совсем не так высоко, как на уроках физкультуры. Спешка — это дополнительные, ненужные усилия. Она указывает на активность, но не на выполнение работы. Движение нетрудно спутать с прогрессом, а занятость с продуктивностью. Главную роль в эффективном программировании играет мышление, а размышляющие люди обычно не кажутся занятыми.
Стив Макконнелл «Совершенный код»
Да кстати у меня периодически бывало, что и 8 часов было мало. Если задача интересна, она не отпускает, даже когда ложишься спать.
P.S. не минусую
Бывает зачастую так, что думаешь, ищешь решение, гуглишь примеры работы, активно «мозгуешь» идею, а потом ложишься спать или идешь кататься на велосипеде и бац, решение созрело в фоновом процессе! Причем были исследования, не «британских» а нормальных ученых как сон позволяет структурировать опыт и обдумывать решение.
Вы описываете обычный творческий процесс, который описан в психологии как изучение, напряжение, открытие.
Тесла изобрел двигатель на переменном токе (если не забыл че) когда его друг просто пинками выгнал в парк, отвлечься от его болезненного занятия наукой. Там его и осенило.
Тут чуть подбробнее только тогда был звук плохой, но интересно. ( с 14:30) Про творчество и наркотики
www.youtube.com/watch?feature=player_detailpage&v=ojCkgU5XGdg#t=809
Тесла изобрел двигатель на переменном токе (если не забыл че) когда его друг просто пинками выгнал в парк, отвлечься от его болезненного занятия наукой. Там его и осенило.
Тут чуть подбробнее только тогда был звук плохой, но интересно. ( с 14:30) Про творчество и наркотики
www.youtube.com/watch?feature=player_detailpage&v=ojCkgU5XGdg#t=809
с 4:50 если точнее
www.youtube.com/watch?v=ojCkgU5XGdg#t=290
www.youtube.com/watch?v=ojCkgU5XGdg#t=290
А Менделеев!
Вот тот ролик про сон.
Вот тот ролик про сон.
НЛО прилетело и опубликовало эту надпись здесь
Вообще-то не зажрались, а таковы реалии рынка труда. Если завтра грянет кризис, работа итшников будет не нужна и людей на рынке станет больше, чем вакансий, то и ценник сильно упадет в низ ("пишу на ХХ за еду"). Механизм тупой и примитивный.
> если проект фейлиться то это начальник мудак
Вообще, строго говоря, в фейлах проектов, как обладающий возможностью принимать решения, всегда виноват менежент. Конечно, к провалу могут приложить руки и рядовые сотрудники, но все равно даже в таком случае в первую очередь виноваты менеджеры, раз они не смогли правильно выстроить кадровую политику и организовать рабочий процесс.
Вообще, строго говоря, в фейлах проектов, как обладающий возможностью принимать решения, всегда виноват менежент. Конечно, к провалу могут приложить руки и рядовые сотрудники, но все равно даже в таком случае в первую очередь виноваты менеджеры, раз они не смогли правильно выстроить кадровую политику и организовать рабочий процесс.
Как, например, при приеме на работу продуктивность и знания разработчика оценивается уполномоченными специалистами компании, после чего существует испытательный срок для валидации KPI работника. В соответствии с этой оценкой сотруднику предлагается заработная плата, отражающая его продуктивность.
А вы ничего не перепутали? Вы это не про землекопов, а про ИТ написали? Тогда, имхо, вы живете в какой-то параллельной вселенной.
Наверно и компания моя живет в параллельной вселенной :). Если нет возможности оценивать продуктивности разработчиков (я не спорю, что это сложно, мы это решаем за счет командной кооперации), то компания, я извиняюсь, в жопе. Ну или разработчики в терроре начальников. Или начальники в терроре разработчиков.
Напишите рассказ подробный, как рассчитываете, что считаете?
Тоже очень интересен опыт оценки производительности разработчиков.
У нас это решается кворумом программистов.
Приходит запрос от начальства, что так и так у такого-то вашего коллеги заканчивается испытательный срок, все кто с ним работал просим к нам.
Мы обсуждаем, защищаем коллегу или наоборот, говорим что не сработаемся.
И уже, только на основании мнения других разработчиков делается решение.
Зарплаты условно открытые, то есть мы можем примерно прикидывать от 10 до 30, от 40 до 60, 70-90 и так далее. Точной суммы никто не знает, да и не положено это, честно говоря. Не то что бы у нас, мое мнение состоит в том, что знать зарлату своего коллеги нельзя, это не даст тебе спокойно жить =)
Ну и после заседания кворума принимается решение то, что группка разработчиков сказала. Если группа сказала, что человеку нужно поднять ЗП, так как он очень хороший и всем кажется что с ним приятно и родуктивно рабротать, то ЗП будет поднята.
Так же кворум собирается по требованию любого из сотрудников — я хочу пересмотреть свою ЗП, например.
Как оценивать KPI мы так и не придумали. Как можно оценить KPI художника? Картин в день? =)
Поэтому мы то ли пришли, то ли остались на схеме, где все решают коллеги.
Но не надо обманываться и думать, что если со всеми дружить, но ничего не делать, то тебя будут покрывать. Ведь если ты ничего не делаешь, это сваливается на плечи твоему соседу и ему это расхлебывать, и уж тут вряд ли он скажет что ты ему помогал и так много сделал за прошлый месяц, он скорее просто промолчит.
Приходит запрос от начальства, что так и так у такого-то вашего коллеги заканчивается испытательный срок, все кто с ним работал просим к нам.
Мы обсуждаем, защищаем коллегу или наоборот, говорим что не сработаемся.
И уже, только на основании мнения других разработчиков делается решение.
Зарплаты условно открытые, то есть мы можем примерно прикидывать от 10 до 30, от 40 до 60, 70-90 и так далее. Точной суммы никто не знает, да и не положено это, честно говоря. Не то что бы у нас, мое мнение состоит в том, что знать зарлату своего коллеги нельзя, это не даст тебе спокойно жить =)
Ну и после заседания кворума принимается решение то, что группка разработчиков сказала. Если группа сказала, что человеку нужно поднять ЗП, так как он очень хороший и всем кажется что с ним приятно и родуктивно рабротать, то ЗП будет поднята.
Так же кворум собирается по требованию любого из сотрудников — я хочу пересмотреть свою ЗП, например.
Как оценивать KPI мы так и не придумали. Как можно оценить KPI художника? Картин в день? =)
Поэтому мы то ли пришли, то ли остались на схеме, где все решают коллеги.
Но не надо обманываться и думать, что если со всеми дружить, но ничего не делать, то тебя будут покрывать. Ведь если ты ничего не делаешь, это сваливается на плечи твоему соседу и ему это расхлебывать, и уж тут вряд ли он скажет что ты ему помогал и так много сделал за прошлый месяц, он скорее просто промолчит.
Я обязательно как-нибудь напишу длинную статью на это тему, могу в комментарии описать основные соображения в первом приближении. Не уверен, интересно ли будет это читать в таком сжатом виде.
У нас есть задача: определить KPI, по которым мы сможем измерять продуктивность отдельных разработчиков. Какие есть варианты: количество написанного кода, количество переписанного кода, количество багов, которые непонятно как считать в больших командах, время сколько открыта iDE и прочее. Не надо особо долго думать, чтобы понять, что это не сработает. Не буду расписывать почему, каждый разработчик поймет как можно удовлетворять критериям и при этом не работать вообще. Продолжая рассуждения можно прийти к выводу, что изолированно оценивать KPI разработчика невозможно.
Что важно для компании? Для компании важно заработать денег, чтобы их заработать надо делать полезный продукт (я работаю в продуктовой компании, поэтому аутсурс сейчас рассматривать не буду. Идеи там те же, но в профиль или в 3/4). Полезный продукт будут покупать, а продукт полезен тем value, который он привносит в решении проблем пользователей. И мы отталкиваемся именно от этого. Работа поделена на мелкие итерации, которые несут частицу value, наблюдаемую и измеримую. Объем каждой замеряется в SP (некие попугаи, специфичные для конкретных команд). В долгосрочной перспективе можно достаточно точно оценить изменение продуктивности при присоединении нового человека. Но эта оценка не так важна, нет никакого смысла мерить разработчика отдельно от команды. В конце концов разработчик работает по разному с субьективными для него «мудаками» и «няшками». Есть только возможности мерить его профессионализм с точки зрения кода и архитектуры и это делают на review кода, при необходимости вынося это в KPI человека (количество архитектурно-концептуальных исправлений при ревью, количество косметических исправлений и так далее).
А вот у команд есть вполне конкретные KPI (например, количество заваленных итерации на каждые пять/десять), их понятно как мерить и от них зависят напрямую деньги, которые получит компания. А команда саморегулируемый организм: если команда несет ответственность за результат и стремиться улучшить бизнес-KPI, то она первая начнет кричать о том, что в ее рядах есть человек плюющий в потолок. В конечном итоге наблюдают за этим процессом scrum master'а и их задача повышать и развивать самостоятельность команды и ее продуктивность.
Ну а вообще, коли мы тут говорим о зп изначально, то тут должен быть большой разговор не о KPI, а о том, почему мотивация деньгами не работает)
У нас есть задача: определить KPI, по которым мы сможем измерять продуктивность отдельных разработчиков. Какие есть варианты: количество написанного кода, количество переписанного кода, количество багов, которые непонятно как считать в больших командах, время сколько открыта iDE и прочее. Не надо особо долго думать, чтобы понять, что это не сработает. Не буду расписывать почему, каждый разработчик поймет как можно удовлетворять критериям и при этом не работать вообще. Продолжая рассуждения можно прийти к выводу, что изолированно оценивать KPI разработчика невозможно.
Что важно для компании? Для компании важно заработать денег, чтобы их заработать надо делать полезный продукт (я работаю в продуктовой компании, поэтому аутсурс сейчас рассматривать не буду. Идеи там те же, но в профиль или в 3/4). Полезный продукт будут покупать, а продукт полезен тем value, который он привносит в решении проблем пользователей. И мы отталкиваемся именно от этого. Работа поделена на мелкие итерации, которые несут частицу value, наблюдаемую и измеримую. Объем каждой замеряется в SP (некие попугаи, специфичные для конкретных команд). В долгосрочной перспективе можно достаточно точно оценить изменение продуктивности при присоединении нового человека. Но эта оценка не так важна, нет никакого смысла мерить разработчика отдельно от команды. В конце концов разработчик работает по разному с субьективными для него «мудаками» и «няшками». Есть только возможности мерить его профессионализм с точки зрения кода и архитектуры и это делают на review кода, при необходимости вынося это в KPI человека (количество архитектурно-концептуальных исправлений при ревью, количество косметических исправлений и так далее).
А вот у команд есть вполне конкретные KPI (например, количество заваленных итерации на каждые пять/десять), их понятно как мерить и от них зависят напрямую деньги, которые получит компания. А команда саморегулируемый организм: если команда несет ответственность за результат и стремиться улучшить бизнес-KPI, то она первая начнет кричать о том, что в ее рядах есть человек плюющий в потолок. В конечном итоге наблюдают за этим процессом scrum master'а и их задача повышать и развивать самостоятельность команды и ее продуктивность.
Ну а вообще, коли мы тут говорим о зп изначально, то тут должен быть большой разговор не о KPI, а о том, почему мотивация деньгами не работает)
> А вот у команд есть вполне конкретные KPI (например, количество заваленных итерации на каждые пять/десять), их понятно как мерить и от них зависят напрямую деньги, которые получит компания.
На предыдущей работе вышестоящий менеджмент мыл мозг командам за то, что они слишком мало спринтов заваливают, потому что по скраму надо заваливать около половины, что должно означать усердную работу команды на грани максимальной стабильной производительности. А если у вас все спринты завершаются успешно, значит вы недобираете задач и работаете «с прохладцей».
На предыдущей работе вышестоящий менеджмент мыл мозг командам за то, что они слишком мало спринтов заваливают, потому что по скраму надо заваливать около половины, что должно означать усердную работу команды на грани максимальной стабильной производительности. А если у вас все спринты завершаются успешно, значит вы недобираете задач и работаете «с прохладцей».
KPI работника и KPI команды это две большие разницы. ИМХО, KPI работника — зло, KPI команды — обязательны к измерению. А вы о каких KPI?
Полностью поддерживаю. Команда из 10 крутых разработчиков, каждый из которых тянет одеяло на себя, будет менее продуктивной, чем сработавшаяся команда середнячков, возглавляемая хорошим тимлидом.
КПД команды можно вдвое повысить хорошим тимлидом и внедрением более эффективных методологий разработки. О каком KPI сотрудника тогда идет речь, если его велечина сильно меняется от внешних причин?
КПД команды можно вдвое повысить хорошим тимлидом и внедрением более эффективных методологий разработки. О каком KPI сотрудника тогда идет речь, если его велечина сильно меняется от внешних причин?
Я приверженец что не существует по сути своей никаких методологий эффективной разработки. Внимание просто переносится на внешние вещи, которые мы всегда читаем или слушаем про эффективность, но забываем, что во всем этом участвуют люди и руководители. Конкретные люди и есть эффективные методы.
Все известные практики могут только намекать на что-то, но как чувствовать людей, как взаимодействовать конкретно с Васей не расскажет ни одна метода. Хочет ли вася программировать или это не его и ему интереснее заниматься другим?
Можно проще, загнать всех по формату, написать в договоре на приеме на работу что переписка будет читаться, что время будет фиксироваться, требоваться отчетность… конечно… болтиками легче управлять, когда общение с человеком сведено до уровня элементарного API. Все гениальные руководители не просто начитаные хмыри) все они уникальны и нам тоже нужно искать свою уникальность. Работать с уникальностью куда интереснее чем с болтиком)
Все известные практики могут только намекать на что-то, но как чувствовать людей, как взаимодействовать конкретно с Васей не расскажет ни одна метода. Хочет ли вася программировать или это не его и ему интереснее заниматься другим?
Можно проще, загнать всех по формату, написать в договоре на приеме на работу что переписка будет читаться, что время будет фиксироваться, требоваться отчетность… конечно… болтиками легче управлять, когда общение с человеком сведено до уровня элементарного API. Все гениальные руководители не просто начитаные хмыри) все они уникальны и нам тоже нужно искать свою уникальность. Работать с уникальностью куда интереснее чем с болтиком)
KPI работника обычно сложно получить, если только речь не идёт о каких-то однотипных работах — т.е. он обычно просто бесполезен.
Но проблема понять как включается в работу новый человек — остаётся. Обычно это просто отдаётся на «ощущения» его лида, т.е. чисто субъективные факторы и общие оценки типа «ну я бы это сделал за день, но для начала неделя это ещё не так плохо».
Видел такую практику что оценку делают исходя из оценки кривой обучения — т.е. не по «ну вот эту оценку он превысил в 2 раза», а по динамике, с попыткой предсказать как скоро человек выйдет в 100% планируемой на него нагрузки.
Но проблема понять как включается в работу новый человек — остаётся. Обычно это просто отдаётся на «ощущения» его лида, т.е. чисто субъективные факторы и общие оценки типа «ну я бы это сделал за день, но для начала неделя это ещё не так плохо».
Видел такую практику что оценку делают исходя из оценки кривой обучения — т.е. не по «ну вот эту оценку он превысил в 2 раза», а по динамике, с попыткой предсказать как скоро человек выйдет в 100% планируемой на него нагрузки.
Я так понимаю, что меряется «KPI команды-с-новым-работником» и сравнивается с KPI-команды-до-нового-работника.
AlexeyRogatkin, я Вас правильно понял?
AlexeyRogatkin, я Вас правильно понял?
Это всего лишь одна из возможностей, я упомянул сразу, что она не имеет особого смысла. Мы это не используем, есть примеры когда это используют. Дело вкуса, метрика достаточно репрезентативна, но много граничных условий. Не всегда есть возможность вводить людей по одному с ожиданием в несколько итераций.
Re: «Знайте. У нас незаменимых нет. После проекта в компании останутся только лучшие.»
Да это же прямо про внутреннюю политику отсева кадров в Microsoft. Не удивительно что они сливаются.
Да это же прямо про внутреннюю политику отсева кадров в Microsoft. Не удивительно что они сливаются.
«Вам не надо знать, зачем вообще это нужно. Надо просто сделать эту хрень и все.»
Вроде логично.
Если начальство просит сделать так, но ты можешь сделать лучше/красивее, чтобы было масштабируемо, но при этом затратить больше времени, то какой вариант выберете? Я вот лично не могу точного ответа дать.
Сам стараюсь всегда делать правильно сразу, даже если говорят «сделай пока так, потом допилим», но вот многие знакомые программисты говорят, что так делать не стоит, ибо может повлиять на сроки сдачи проекта самовольность эта и т.д.
Вроде логично.
Если начальство просит сделать так, но ты можешь сделать лучше/красивее, чтобы было масштабируемо, но при этом затратить больше времени, то какой вариант выберете? Я вот лично не могу точного ответа дать.
Сам стараюсь всегда делать правильно сразу, даже если говорят «сделай пока так, потом допилим», но вот многие знакомые программисты говорят, что так делать не стоит, ибо может повлиять на сроки сдачи проекта самовольность эта и т.д.
«Вам не надо знать, зачем вообще это нужно. Надо просто сделать эту хрень и все.»
Так обычно говорят когда у человека миллион контактов в сутки и очень сложно в голове держать кому сообщил кому не сообщил информацию, потому часто просто требуют так как проще без вопросов.
Так обычно говорят когда у человека миллион контактов в сутки и очень сложно в голове держать кому сообщил кому не сообщил информацию, потому часто просто требуют так как проще без вопросов.
Мне кажется, что тут имеется в виду процесс разработки без понимания сути задачи. Например, задача «брать одно значение, умножать на 5 и делить на 2, а ко второму прибавлять 5.238». «Просто сделать эту хрень» это a = a*5/2, b += 5.238. И запрещено пытаться вникнуть в физический смысл этих значений и операций. И вот ты в трех местах это скопипастил, а потом оказывается, что 5.238 это курс валюты, который надо поддерживать актуальным, а между 5, 2 и 5.238 есть некая зависимость. И обречен ты вечно искать по всему коду эти прямые значения, потому что ты даже не знал как константу назвать, ибо черт его знает кто такие 5 и 2.
Логично в случае если это бизнес фича, или вам сказали просто быстро поправить какой-то баг. А вот что делать когда директор говорит «вам нужно использовать только один ключ шифрования а не два. Ну и что с того что некоторые сообщения не смогут быть расшифрованы на клиенте. Наша система не гарантирует доставку сообщений. Делайте а не спорьте»? Ситуация не выдуманная, случилась лично со мной. Вот такое вмешательство во внутреннюю кухню проекта отбивает всякое желание работать с подобными людьми.
У меня остался маленький словарик с великолепными фразами. Как вспоминаю, так смех берет))
«Ты почему не продвинул сайт по этому запросу! Они орут просто на меня! — ну так я тебя спрашивал, ты сказал точно что не нужно по этому запросу. — Ну так ты же специалист! Емае, я говорю, ну как так. Почему ты меня непереубедил что я был не прав. Мало ли что я говорю, если ты считаешь что это не так, ты должен добиться от меня верного ответа как специалист! Блин, ну ема-е! Почему ты так поступил??.
Или
— Андрюх, это ты поля неправильно назвал? Точнее это я так сделал, но ты не захотел это поправить!!!
или
Але? Да да да… я понял. Я помню. У нас что-то с почтой, я сейчас все вышлю, то есть не сейчас а до 13 точно, то есть в течении часа постараюсь…
Через сутки другие:
— Але, нет не забыли. Я уже отдал в разработку. Когда ждать? Ну это как только так отпишем сразу. Когда примерно? Ну давайте сего… Завтра в районе обеда я вам отпишу что у нас как происходит.
«Ты почему не продвинул сайт по этому запросу! Они орут просто на меня! — ну так я тебя спрашивал, ты сказал точно что не нужно по этому запросу. — Ну так ты же специалист! Емае, я говорю, ну как так. Почему ты меня непереубедил что я был не прав. Мало ли что я говорю, если ты считаешь что это не так, ты должен добиться от меня верного ответа как специалист! Блин, ну ема-е! Почему ты так поступил??.
Или
— Андрюх, это ты поля неправильно назвал? Точнее это я так сделал, но ты не захотел это поправить!!!
или
Але? Да да да… я понял. Я помню. У нас что-то с почтой, я сейчас все вышлю, то есть не сейчас а до 13 точно, то есть в течении часа постараюсь…
Через сутки другие:
— Але, нет не забыли. Я уже отдал в разработку. Когда ждать? Ну это как только так отпишем сразу. Когда примерно? Ну давайте сего… Завтра в районе обеда я вам отпишу что у нас как происходит.
А может быть беда в том, что руководство компаний (особенно мелких) так и не научилось делегировать? Каждый боится за свои деньги и тот кто боится больше пытается вмешаться и управлять процессом. Не смотря на то, что его скилы этого не позволяют.
Многое применимо и к системным администраторам. Что характерно, везде, где IT рулят подобные персонажи, инфраструктура находится в глубокой заднице и вообще непонятно, как это еще работает. И наоборот.
— Сколько времени тебе надо на программу?
— Думаю, месяца через три я уже смогу что-нибудь показать, там видно будет.
(проходит 3 месяца)
— Привет. Ну что, программа готова? Мы её двум заказчикам продали, пора уже поставлять.
— o_O
— Думаю, месяца через три я уже смогу что-нибудь показать, там видно будет.
(проходит 3 месяца)
— Привет. Ну что, программа готова? Мы её двум заказчикам продали, пора уже поставлять.
— o_O
22. Вам мешает шум в офисе? Объявления секретаря о приходе нового сотрудника — это акт единства команды при знакомстве с новым коллегой, не важно, что он не в вашей команде будет работать, это наша традиция.
> 21. И, последнее. Знайте. У нас незаменимых нет. После проекта в компании останутся только лучшие.
Напомнило: "- Кукушка-кукушка, сколько мне жить осталось? — Ку! — А почему так ма...."
Останутся как раз не лучшие, а те, кто смог усидеть, или кому оказалось незачем или пока некуда направить стопы.
Напомнило: "- Кукушка-кукушка, сколько мне жить осталось? — Ку! — А почему так ма...."
Останутся как раз не лучшие, а те, кто смог усидеть, или кому оказалось незачем или пока некуда направить стопы.
Почему нельзя без дизайнера GUI? Профессиональный программист сам должен уметь разработать качественный интерфейс.
Зачем тебе диздок/тз? Это документация для геймдизов/менеджеров. Профессиональный программист сам знает, что и как ему нужно сделать.
Почему ты делаешь отсебятину? Профессиональный программист всегда ориентируется на нужды проекта и выполняет только то, что требует руководство.
Как это, время выполнения работы это величина статистическая? Профессиональный программист всегда даёт точную оценку сроков.
Как это, нельзя выполнить работу, т.к. она зависит от других людей? Профессиональный программист может сделать работу любого специалиста сам, а потом в считанные минуты заимплементить любые новые ресурсы в проект.
Зачем нужны тестеры? Профессиональный программист не допускает ошибок в своём проекте.
Почему тебя не нужно отвлекать, самый важный что ли? Профессиональный программист работает легко и эффективно участвуя в чате на 60 человек, в котором обсуждают фотки котиков и политику.
Зачем тебе права админа или хотя бы ПО? Как это работа встала? Профессиональный программист нуждается только в среде разработки и почтовом клиенте.
Вам не надо знать, зачем вообще это нужно. Надо просто сделать эту хрень и все
Вообще, бывают такие проекты где на вопрос «а зачем эта штука нужна?» отвечать запрещено заказчиком.
Но, конечно, в таком случае надо быть особенно вежливым и осторожным в беседах с лицами, ответственными за исполнение. А то чего доброго, начнут думать зачем такая штука может быть нужна.
Мне как-то бывший начальник сказанул «всё упирается только в деньги и время, твои таланты и скилы можно конвертировать в эти составляющие».
Это было начало конца.
Это было начало конца.
Дуракам полработы не показывают.
Спорный момент, требующий уточнения. Как показывает практика, GUI лучше показывать полностью нарисованным, пусть там половина будет просто нерабочими «затычками», но это избавит от множества недоразумений. Пусть будет лучше мёртвая таблица с вколоченными именами, чем дырка которую надо пояснять «ну-у-у тут будет супер-пупер список с возможностью сортировки и т.п.»
Добавлю новый пункт — начальник, который «сейчас я вам буду показывать как правильно ...».
И дизайны он лучше знает, и кластер построить может на листочке, и железо закупить по принципу «тут что-то непонятное дешево отдавали, я взял на всякий случай — вдруг пригодится», и архитектуру приложения он сам придумывает и сам рисует на листочке.
Жаль только, что босс-«гуру» обычно лишь жутко мешает и тормозит процесс…
И дизайны он лучше знает, и кластер построить может на листочке, и железо закупить по принципу «тут что-то непонятное дешево отдавали, я взял на всякий случай — вдруг пригодится», и архитектуру приложения он сам придумывает и сам рисует на листочке.
Жаль только, что босс-«гуру» обычно лишь жутко мешает и тормозит процесс…
Не мало важную роль играет обратная связь — нет вопросов к нему почему это лишнее, значит так и будет продолжаться.
Оооо вы правы, по-моему нет зверя страшнее чем начальник лезущий во все дыры, и стремящийся сделать все работу ( часто самую интересную ее часть ) за каждого члена команды.
По-моему это очень важно дать человеку самому принять решение, и потом позволить воплощать его в жизнь. Свои решения тем и отличаются от чужих, что ты за них чувствуешь большую ответственность, и тебе хочется их реализовать. Чужое же ( пусть даже оно не хуже твоего ) — тебе будет не так ценно само по себе, и часто можно подсознательно искать в нем недостатки вместо того чтобы просто сделать и забыть.
По-моему это очень важно дать человеку самому принять решение, и потом позволить воплощать его в жизнь. Свои решения тем и отличаются от чужих, что ты за них чувствуешь большую ответственность, и тебе хочется их реализовать. Чужое же ( пусть даже оно не хуже твоего ) — тебе будет не так ценно само по себе, и часто можно подсознательно искать в нем недостатки вместо того чтобы просто сделать и забыть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как потерять капитал