Девять вещей, которые нужны разработчикам больше, чем деньги
Девять вещей, которые нужны разработчикам больше, чем деньги
резюме статьи Роба Уаллинга (Rob Walling):
http://www.habrahabr.ru/blog/pm/4683.html
Деньги — это сильная мотивация, но они порой не являются конечным и решающим фактором в борьбе за хороших работников.
1. Начать, чтобы преуспеть
Это грустная правда, но много проектов по разработке ПО провальны. У каждого разработчика есть в запасе истории и контр-примеры плохого управления проектами.
Реалистичные дедлайны — это основа успеха проекта. Разработчики хотят делать ПО, которое не только работает, но которое не стыдно показать, и которым они потом смогут гордиться. Этот принцип часто расходится с целями, поставленными руководством, которое хочет получить просто работающее ПО.
Вообще, первое, что страдает при недостатке времени, — это качество и надёжность. Самое больше зло, которые вы можете принести разработчику — это заставить его делать туфту. О какой гордости за свой труд потом может идти речь?
Работу нужно делать не только быстро, но и качественно. Один разработчик, с которым я общался, сказал: "Качество так же важно, как бюджет и функциональность."
2. Отличное руководство
Хорошее управление проектом важно как для самого проекта, так и для людей, которые будут мотивированы великолепным менеджментом. Это означает уметь выслушать независимую точку зрения, знать, чего стоит разработка качественного продукта, уметь быстро принимать решения и уметь брать на себя ответственность за всю команду.
3. Обучение чему-то новому
Исследования поведения людей показывают, что мы более комфортно себя чувствуем, когда мы учимся новым вещам. Два исследователя из Колумбийского университета сделали вывод, что работники готовы отказаться в среднем от 20%-го повышения, если работа станет более разнообразной или потребует более обширные знания предмета. Фактически, мы выбираем меньшую зарплату в пользу забавной, интересной для нас работы, которая ещё и позволяет расширять и углублять свои знания.
Каждый разработчик, которого я знаю, любит играться с новыми технологиями. Возможность насытить потребность к изучению новым вещам должна быть у каждого. Позволяйте своим работникам учиться, и они будут счастливы на работе даже в безоконном подвальном помещении, где несвежая еда подаётся через маленькое окошко. И они не обмолвятся о повышении.
4. Креативность и решение настоящих проблем
Разработчики любят, когда им бросают вызов. Без борьбы им скучно: они начинают проверять почту, посещать Digg и Slashdot, читать блоги и смотреть, кто из знакомых находится онлайн только ради того, чтобы поболтать о своём дяде, об интерфейсе IDisposable или куске тоста, имеющем форму Святой Марии.
Сколько раз я видел разработчиков, которые до рассвета решали технические неполадки даже тогда, когда их об этом не просили, а о сверхурочных даже никто не заикался. Лучшие разработчики просто живут решением проблем. Большинство этих людей не оставят дело до тех пор, пока проблема не будет устранена, а ещё больше их затянет то, что задача будет требовать нестандартного подхода.
5. Право голоса
Разработчики — это те люди, которые узнают о неработающей системе или процессе первыми. Один раз я слышал: "Я хочу, чтобы кто-то прислушался к моим проблемам и отнёсся к ним серьёзно. Я работал в нескольких местах, где объём памяти, кол-во жёстких дисков и тактовая частота процессора просто не интересовала руководство компании. Каждый раз приходилось удалять временные файлы, потому что не хватало места на диске. Знаете, работа с устаревшим оборудованием просто раздражает."
Когда разработчик говорит, кто-то должен его слушать. Когда несколько разработчиков говорят об одном и том же, то кто-то обязан выслушать их и быстро действовать.
6. Признание для тяжёлой работы
Разработчики любят трудные задания и работу, которая производит впечатление на них самих и их друзей.
7. Создание чего-то важного
Мы не доктора в Боснии и даже не носильщики еды в Судане, но тем не менее, много людей чувствует, что хотели бы сделать что-то полезное для мира, что-то социальное и технологическое одновременно. Системный инженер, создавший логистическую систему, которая сократит километраж пути, проделанного машинами для каждодневного развоза прессы, будет иметь больше радости, чем программист, написавший программу, которая будет запущена от силы раз 15 за целый год.
Копи-пейст кусков кода с изменениями лейблов на самом деле не такая интересная работа, как может показаться.
8. Создание ПО не должно сопровождаться излишней бюрократией
Я работал по контракту в течение трёх лет с 2001 года. За это время я написал массу веб-приложений. Я легко писал код, когда точно знал, что и как делать. Вместе с одним разработчиком мы на пару написали тонны ПО. А, вот, на моей следующей работе производство ПО можно было сравнить с тасканием гирей. Создание каждой новой страницы требовало созыв шести людей для одобрения изменений. Разработка тянулась в 5 раз дольше. Это довольно раздражает. Возможность принимать решения без заседания группы людей очень и очень облегчает работу.
9. Малое количество ограничений
Ужасный код, баги в интерфейсе и плохо разработанная модель данных не нравятся никому. Слишком много ограничений сокращает творческую составляющую, заставляет собирать собрания для принятия решений по изменениям и вообще, отбивает всё желание выкладываться в работе над проектом.
Девять вещей, которые нужны разработчикам больше, чем деньги
резюме статьи Роба Уаллинга (Rob Walling):
http://www.habrahabr.ru/blog/pm/4683.html
Деньги — это сильная мотивация, но они порой не являются конечным и решающим фактором в борьбе за хороших работников.
1. Начать, чтобы преуспеть
Это грустная правда, но много проектов по разработке ПО провальны. У каждого разработчика есть в запасе истории и контр-примеры плохого управления проектами.
Реалистичные дедлайны — это основа успеха проекта. Разработчики хотят делать ПО, которое не только работает, но которое не стыдно показать, и которым они потом смогут гордиться. Этот принцип часто расходится с целями, поставленными руководством, которое хочет получить просто работающее ПО.
Вообще, первое, что страдает при недостатке времени, — это качество и надёжность. Самое больше зло, которые вы можете принести разработчику — это заставить его делать туфту. О какой гордости за свой труд потом может идти речь?
Работу нужно делать не только быстро, но и качественно. Один разработчик, с которым я общался, сказал: "Качество так же важно, как бюджет и функциональность."
2. Отличное руководство
Хорошее управление проектом важно как для самого проекта, так и для людей, которые будут мотивированы великолепным менеджментом. Это означает уметь выслушать независимую точку зрения, знать, чего стоит разработка качественного продукта, уметь быстро принимать решения и уметь брать на себя ответственность за всю команду.
3. Обучение чему-то новому
Исследования поведения людей показывают, что мы более комфортно себя чувствуем, когда мы учимся новым вещам. Два исследователя из Колумбийского университета сделали вывод, что работники готовы отказаться в среднем от 20%-го повышения, если работа станет более разнообразной или потребует более обширные знания предмета. Фактически, мы выбираем меньшую зарплату в пользу забавной, интересной для нас работы, которая ещё и позволяет расширять и углублять свои знания.
Каждый разработчик, которого я знаю, любит играться с новыми технологиями. Возможность насытить потребность к изучению новым вещам должна быть у каждого. Позволяйте своим работникам учиться, и они будут счастливы на работе даже в безоконном подвальном помещении, где несвежая еда подаётся через маленькое окошко. И они не обмолвятся о повышении.
4. Креативность и решение настоящих проблем
Разработчики любят, когда им бросают вызов. Без борьбы им скучно: они начинают проверять почту, посещать Digg и Slashdot, читать блоги и смотреть, кто из знакомых находится онлайн только ради того, чтобы поболтать о своём дяде, об интерфейсе IDisposable или куске тоста, имеющем форму Святой Марии.
Сколько раз я видел разработчиков, которые до рассвета решали технические неполадки даже тогда, когда их об этом не просили, а о сверхурочных даже никто не заикался. Лучшие разработчики просто живут решением проблем. Большинство этих людей не оставят дело до тех пор, пока проблема не будет устранена, а ещё больше их затянет то, что задача будет требовать нестандартного подхода.
5. Право голоса
Разработчики — это те люди, которые узнают о неработающей системе или процессе первыми. Один раз я слышал: "Я хочу, чтобы кто-то прислушался к моим проблемам и отнёсся к ним серьёзно. Я работал в нескольких местах, где объём памяти, кол-во жёстких дисков и тактовая частота процессора просто не интересовала руководство компании. Каждый раз приходилось удалять временные файлы, потому что не хватало места на диске. Знаете, работа с устаревшим оборудованием просто раздражает."
Когда разработчик говорит, кто-то должен его слушать. Когда несколько разработчиков говорят об одном и том же, то кто-то обязан выслушать их и быстро действовать.
6. Признание для тяжёлой работы
Разработчики любят трудные задания и работу, которая производит впечатление на них самих и их друзей.
7. Создание чего-то важного
Мы не доктора в Боснии и даже не носильщики еды в Судане, но тем не менее, много людей чувствует, что хотели бы сделать что-то полезное для мира, что-то социальное и технологическое одновременно. Системный инженер, создавший логистическую систему, которая сократит километраж пути, проделанного машинами для каждодневного развоза прессы, будет иметь больше радости, чем программист, написавший программу, которая будет запущена от силы раз 15 за целый год.
Копи-пейст кусков кода с изменениями лейблов на самом деле не такая интересная работа, как может показаться.
8. Создание ПО не должно сопровождаться излишней бюрократией
Я работал по контракту в течение трёх лет с 2001 года. За это время я написал массу веб-приложений. Я легко писал код, когда точно знал, что и как делать. Вместе с одним разработчиком мы на пару написали тонны ПО. А, вот, на моей следующей работе производство ПО можно было сравнить с тасканием гирей. Создание каждой новой страницы требовало созыв шести людей для одобрения изменений. Разработка тянулась в 5 раз дольше. Это довольно раздражает. Возможность принимать решения без заседания группы людей очень и очень облегчает работу.
9. Малое количество ограничений
Ужасный код, баги в интерфейсе и плохо разработанная модель данных не нравятся никому. Слишком много ограничений сокращает творческую составляющую, заставляет собирать собрания для принятия решений по изменениям и вообще, отбивает всё желание выкладываться в работе над проектом.
