Предыдущая статья была достаточно популярна. Я обещал продолжить и держу слово. Делюсь своим личным мнением и не претендую на истину.
В этой части пойдет речь про работу с программистами.
Из опыта внедрений различных методологий Agile сделал следующие выводы
1. Вполне понятным кажущимся решением многим кажется использование типовых советов. Вера в серебряную пулю, джинна из бутылки свойственно большинству людей, менеджеры проектов — не исключение.
2. В последние годы популярным распиаренным решением стали всевозможные гибкие методики, ��ро которые не писал только ленивый. Об этом качестве людей подробно будет ниже.
3. Однако, на практике внедрение чаще всего вместо ожидаемого порядка из хаоса не приводит к автоматическому повышению управляемости процессом разработки. Как правило, благодаря тому, что тупо берется некий каркас, но при этом не учитываются глубинные причины простоев. Некоторые успехи, конечно, есть — как есть и у раздельного питания, к примеру. Но в случае с раздельным питанием люди просто начинают следить за тем, что едят, и уже это часто помогает вкупе с плацебо. Так и метолодолии могут дать эффект, если раньше просто был просто хаос.
4. Как ответ разработчиков на все это, появились знаменитый английский манифест «Programming, Motherfucker! Do you speak it?» и его русский вариант.
5. В конечном счете, вода камень точит. Не буду утверждать, что методологиями в стиле «потратим час на [censored] болтовню» программистов достали, но какая-то доля влияния здесь есть. Наиболее рутинные куски в разработке стандартизовали и автоматизировали — и все чаще стали появляться прекрасные статьи от Яндекса, Badoo и так далее, как выстроен процесс разработки. Где большое внимание уделено техническим инструментам, которые реально роляют на процесс разработки, в отличие от бесконечных плясок с бубном.
Хочу отметить, что с программистами, которые умны и хотят работать, достаточно легко взаимодействовать. Вы объясняете человеку, зачем нужен функционал, и обсуждаете user stories. Какие-то архитектурные моменты. И дальше человек реализует то, что нужно, точно и красиво.
При этом время, потраченное на поиск таких программистов, окупается сторицей. Нежели чем вы просто наберете рэндомных людей и будете пытаться с их помощью построить некую «разработку», применяя «методологии». Если будут хорошие люди — инструменты для себя они напишут, или возьмут готовые.
Кадры решают все, об этом сто раз писали, но грабли до сих пор свеженькие и отполированные новыми лбами.
Хочется сразу отметить, что я не верю в теоретические знания. Можно прочитать сто книжек и сдать на PMI, MBA и множество других слов, но заваливать все проекты. А можно и делать проекты, как пирожки, не владея ценными «знаниями».
Речь пойдет о навыке, которые развивается в процессе практики. Хочу привести лишь пару примеров, чтобы было понятно, в каком направлении мыслить и какой эффект это может дать.
Кейс 1. Делается рассылка e-mail писем, ссылка в которых ведет на лэндинг. Встает задача у молодого менеджера проектов, ограничить от спама форму на лэндинге.
Берется пример у другой рабочей группы, как сделать такую защиту на 8+ часов.
И тут приходит более опытный человек, и предлагает внимательно изучить начальные условия. Лэндинг предназначен только для открытия из почтовых писем.
Следовательно, в первой версии достаточно в ссылках из писем ставить некий ключ в URL, который будет вызывать показ формы на лэндинге. А при прямом заходе форму не показывать.
Придумать — одна минута, делать — 15 минут. Против 8+ часов. Без комментариев.
Кейс 2. Обращается ко мне менеджер проектов. Нужно, мол провести опрос на проекте. Был какой-то движок опросов, можно ли его прикрутить, или писать свой.
Последовательно задаются вопросы
— Сколько раз нужно проводить опрос? Ответ: один раз
— Будут ли меняться поля: Ответ: нет, не будут.
— Сколько участвует в опросе пользователей. Ответ: десяток.
Через минуту выдаю решение — сделать форму на Гугл Докс, и поставить на проекте ссылку. Реализация — минуты, против дней на прикрутку движка опросов, отладку, вынос на релиз и так далее.
Сюда же относится и занос контента статикой (HTML), если он не меняется чаще раза в месяц, вместо создания движка и WYSIWYG, и много других вещей.
Овладев уточнением исходных условием и держа мысль в голове «как это можно сделать проще и быстрее», вы можете значительно ускорить разработку. И научить этому своих программистов.
Программисты, как и любые другие творческие личности, уникальны. Ведь не стали бы вы общаться с Азимовым в роли издателя так, как общались бы с Толстым. А с Пушкиным тоже бы вели свой диалог.
У каждой яркой личности есть свои плюсы и минусы. Нередко при этом программистов, как сложных и непонятных для нетехнарей, пытаются классифицировать определенным образом. И применять стандартные методики, фразы, вопросы.
Начинается все с шаблонных вопросов на собеседовании про «кем вы видите ��ебя в компании через 5 лет», и может продолжаться весь срок работы человека в компании.
Это возможно, но для работы с талантами, мне кажется, не очень подходит.
Например, у меня работает талантливый программист, в прошлом дизайнер и верстальщик. Достаточно уникальный опыт, и поэтому с ним в процессе общения и постановки задач можно не беспокоиться, что он сделает некрасиво. И задачи я подбираю такие, которые наиболее точно позволят ему раскрыться. Мне кажется, это его мотивирует — и неспроста он уже развивает целые проекты в моем отделе.
А есть программист — спец по ООП. Он очень надежный, и всегда все проверяет. Но любит усложнять. И с ним можно в общении не беспокоиться, что в релиз попадет неработающий функционал.
В итоге, когда поступает проект, можно делить его на блоки, которые наилучшим образом соотносятся со способностями команды, что очевидным образом сказывается на эффективности и производительности.
Каждый программист имеет свои способности, свое прошлое, и индивидуальный подход, по моему мнение — то, что может повысить вашу продуктивность работы с командой в разы. Гораздо лучше, чем всех согнать в один опен-спейс, чтобы люди чаще болели и мешали друг другу шумом, несмотря на то, что это рекомендуют разные «дипломированные ребята». Демарко писал об этом 20 лет назад и до сих пор актуален.
Степан Демура, неоднозначный, но яркий трейдер как-то сказал, что если вы будете стоять на рынке так же, как и толпа, то вы обязательно проиграете.
Как ни странно, это правило работает и в управлении проектами. Чем больше будет вокруг суеты, в топиках — стадного чувства, тем меньше советую идти на поводу у инстинктов.
Мы когда-то, как и все, кинулись делать городской портал. И были побиты конкурентами. Хотя, казалось бы, все делают, и у всех должно получиться.
Увы, есть простая аналогия, которая говорит, что ресурсов почти всегда меньше, чем их потенциальных потребителей, и имеет место конкуренция.
Вот стоит палатка с молоком, и в день ходит 100 человек. Палатка успешна, и появляются конкуренты 2,3,4,...N. А как ходило 100 человек, так и ходит. Но прибыль каждой уменьшается с появлением новых, и в конечном итоге разоряются все (один из вариантов сценария).
Вот и так происходит с новыми нишами в бизнесе (вспомните те же купонаторы).
Есть и другой пример, где данная рекомендация работает чуть иначе.
Вчера все сидят на NoSQL, сегодня пилят на jQuery, завтра SVG+HTML5, послезавтра 3d для FaceculusRift.
В итоге, следуя за модой на технологии, вы получаете проект-зоопарк, где дружить технологии все труднее и труднее. Примеров много.
В противоположность один известный сайт бронирования отелей, работающий на [censored] мамонтов Perl. Я на Perl не писал уже лет 10, и все жду легендарного Перла 6. Офигенный был язык (и остается). Насколько я знаю, ежики колются, плюются, но продолжают жрать кактус. И проект растет и развивается, не страдая от резкий падений «а потом мы переписали все на Джаве (подставьте ваш язык) и купили еще 1000 серверов, чтобы не падало каждый час».
Такие неочевидные вещи, которые начинаются с мышления и управления своим выбором, казалось бы, мало относятся к разработке. Но с мысли начинается одержимость, а где одержимость — там фанатизм. Который и приводит к стратегическим фейлам.
Вот говорят, на дизайне исправить ошибку в 1000 раз дешевле, чем на продакшене. А в мышлении — в infinity раз. Только мало кто задумывается об этом, судя по неудачным стартапам повсюду.
Вот говорят, что рыбак рыбака узнает издалека. Даже если вы ничего не прочитали и просто прокрутили вниз, вы уже получите пользу.
Если вы научитесь программировать, то обойдете сотни тысяч молодых парней и девушек, кто мечтает о высокой зарплате в IT, но хотят только управлять.
Ибо своих любят и признают в любой среде, а если руководитель программиста технически подкован, то это дает +1000 (ИМХО) к скиллу уважения.
Но, по исследованиям, к авторитетам лучше прислушиваются.
Приложу хорошую ссылку (еще еще одна) и ролик выдающихся и известных людей, почему вам стоит научиться программировать.
В комментариях предлагаю поделиться вашими находками из опыта, какими-то кейсами, которые считаете интересными.
В этой части пойдет речь про работу с программистами.
1. Вместо костылей нужен фундамент. Люди, а не методологии
Из опыта внедрений различных методологий Agile сделал следующие выводы
1. Вполне понятным кажущимся решением многим кажется использование типовых советов. Вера в серебряную пулю, джинна из бутылки свойственно большинству людей, менеджеры проектов — не исключение.
2. В последние годы популярным распиаренным решением стали всевозможные гибкие методики, ��ро которые не писал только ленивый. Об этом качестве людей подробно будет ниже.
3. Однако, на практике внедрение чаще всего вместо ожидаемого порядка из хаоса не приводит к автоматическому повышению управляемости процессом разработки. Как правило, благодаря тому, что тупо берется некий каркас, но при этом не учитываются глубинные причины простоев. Некоторые успехи, конечно, есть — как есть и у раздельного питания, к примеру. Но в случае с раздельным питанием люди просто начинают следить за тем, что едят, и уже это часто помогает вкупе с плацебо. Так и метолодолии могут дать эффект, если раньше просто был просто хаос.
4. Как ответ разработчиков на все это, появились знаменитый английский манифест «Programming, Motherfucker! Do you speak it?» и его русский вариант.
5. В конечном счете, вода камень точит. Не буду утверждать, что методологиями в стиле «потратим час на [censored] болтовню» программистов достали, но какая-то доля влияния здесь есть. Наиболее рутинные куски в разработке стандартизовали и автоматизировали — и все чаще стали появляться прекрасные статьи от Яндекса, Badoo и так далее, как выстроен процесс разработки. Где большое внимание уделено техническим инструментам, которые реально роляют на процесс разработки, в отличие от бесконечных плясок с бубном.
Хочу отметить, что с программистами, которые умны и хотят работать, достаточно легко взаимодействовать. Вы объясняете человеку, зачем нужен функционал, и обсуждаете user stories. Какие-то архитектурные моменты. И дальше человек реализует то, что нужно, точно и красиво.
При этом время, потраченное на поиск таких программистов, окупается сторицей. Нежели чем вы просто наберете рэндомных людей и будете пытаться с их помощью построить некую «разработку», применяя «методологии». Если будут хорошие люди — инструменты для себя они напишут, или возьмут готовые.
Кадры решают все, об этом сто раз писали, но грабли до сих пор свеженькие и отполированные новыми лбами.
2. Управление требованиями и входными данными как эффективное средство упрощения задач
Хочется сразу отметить, что я не верю в теоретические знания. Можно прочитать сто книжек и сдать на PMI, MBA и множество других слов, но заваливать все проекты. А можно и делать проекты, как пирожки, не владея ценными «знаниями».
Речь пойдет о навыке, которые развивается в процессе практики. Хочу привести лишь пару примеров, чтобы было понятно, в каком направлении мыслить и какой эффект это может дать.
Кейс 1. Делается рассылка e-mail писем, ссылка в которых ведет на лэндинг. Встает задача у молодого менеджера проектов, ограничить от спама форму на лэндинге.
Берется пример у другой рабочей группы, как сделать такую защиту на 8+ часов.
И тут приходит более опытный человек, и предлагает внимательно изучить начальные условия. Лэндинг предназначен только для открытия из почтовых писем.
Следовательно, в первой версии достаточно в ссылках из писем ставить некий ключ в URL, который будет вызывать показ формы на лэндинге. А при прямом заходе форму не показывать.
Придумать — одна минута, делать — 15 минут. Против 8+ часов. Без комментариев.
Кейс 2. Обращается ко мне менеджер проектов. Нужно, мол провести опрос на проекте. Был какой-то движок опросов, можно ли его прикрутить, или писать свой.
Последовательно задаются вопросы
— Сколько раз нужно проводить опрос? Ответ: один раз
— Будут ли меняться поля: Ответ: нет, не будут.
— Сколько участвует в опросе пользователей. Ответ: десяток.
Через минуту выдаю решение — сделать форму на Гугл Докс, и поставить на проекте ссылку. Реализация — минуты, против дней на прикрутку движка опросов, отладку, вынос на релиз и так далее.
Сюда же относится и занос контента статикой (HTML), если он не меняется чаще раза в месяц, вместо создания движка и WYSIWYG, и много других вещей.
Овладев уточнением исходных условием и держа мысль в голове «как это можно сделать проще и быстрее», вы можете значительно ускорить разработку. И научить этому своих программистов.
3. Раскрытие личностного потенциала вместо шаблонного общения
Программисты, как и любые другие творческие личности, уникальны. Ведь не стали бы вы общаться с Азимовым в роли издателя так, как общались бы с Толстым. А с Пушкиным тоже бы вели свой диалог.
У каждой яркой личности есть свои плюсы и минусы. Нередко при этом программистов, как сложных и непонятных для нетехнарей, пытаются классифицировать определенным образом. И применять стандартные методики, фразы, вопросы.
Начинается все с шаблонных вопросов на собеседовании про «кем вы видите ��ебя в компании через 5 лет», и может продолжаться весь срок работы человека в компании.
Это возможно, но для работы с талантами, мне кажется, не очень подходит.
Например, у меня работает талантливый программист, в прошлом дизайнер и верстальщик. Достаточно уникальный опыт, и поэтому с ним в процессе общения и постановки задач можно не беспокоиться, что он сделает некрасиво. И задачи я подбираю такие, которые наиболее точно позволят ему раскрыться. Мне кажется, это его мотивирует — и неспроста он уже развивает целые проекты в моем отделе.
А есть программист — спец по ООП. Он очень надежный, и всегда все проверяет. Но любит усложнять. И с ним можно в общении не беспокоиться, что в релиз попадет неработающий функционал.
В итоге, когда поступает проект, можно делить его на блоки, которые наилучшим образом соотносятся со способностями команды, что очевидным образом сказывается на эффективности и производительности.
Каждый программист имеет свои способности, свое прошлое, и индивидуальный подход, по моему мнение — то, что может повысить вашу продуктивность работы с командой в разы. Гораздо лучше, чем всех согнать в один опен-спейс, чтобы люди чаще болели и мешали друг другу шумом, несмотря на то, что это рекомендуют разные «дипломированные ребята». Демарко писал об этом 20 лет назад и до сих пор актуален.
4. Не идите за всеми — это нередко кончается провалом
Степан Демура, неоднозначный, но яркий трейдер как-то сказал, что если вы будете стоять на рынке так же, как и толпа, то вы обязательно проиграете.
Как ни странно, это правило работает и в управлении проектами. Чем больше будет вокруг суеты, в топиках — стадного чувства, тем меньше советую идти на поводу у инстинктов.
Мы когда-то, как и все, кинулись делать городской портал. И были побиты конкурентами. Хотя, казалось бы, все делают, и у всех должно получиться.
Увы, есть простая аналогия, которая говорит, что ресурсов почти всегда меньше, чем их потенциальных потребителей, и имеет место конкуренция.
Вот стоит палатка с молоком, и в день ходит 100 человек. Палатка успешна, и появляются конкуренты 2,3,4,...N. А как ходило 100 человек, так и ходит. Но прибыль каждой уменьшается с появлением новых, и в конечном итоге разоряются все (один из вариантов сценария).
Вот и так происходит с новыми нишами в бизнесе (вспомните те же купонаторы).
Есть и другой пример, где данная рекомендация работает чуть иначе.
Вчера все сидят на NoSQL, сегодня пилят на jQuery, завтра SVG+HTML5, послезавтра 3d для FaceculusRift.
В итоге, следуя за модой на технологии, вы получаете проект-зоопарк, где дружить технологии все труднее и труднее. Примеров много.
В противоположность один известный сайт бронирования отелей, работающий на [censored] мамонтов Perl. Я на Perl не писал уже лет 10, и все жду легендарного Перла 6. Офигенный был язык (и остается). Насколько я знаю, ежики колются, плюются, но продолжают жрать кактус. И проект растет и развивается, не страдая от резкий падений «а потом мы переписали все на Джаве (подставьте ваш язык) и купили еще 1000 серверов, чтобы не падало каждый час».
Такие неочевидные вещи, которые начинаются с мышления и управления своим выбором, казалось бы, мало относятся к разработке. Но с мысли начинается одержимость, а где одержимость — там фанатизм. Который и приводит к стратегическим фейлам.
Вот говорят, на дизайне исправить ошибку в 1000 раз дешевле, чем на продакшене. А в мышлении — в infinity раз. Только мало кто задумывается об этом, судя по неудачным стартапам повсюду.
5. Научитесь программировать
Вот говорят, что рыбак рыбака узнает издалека. Даже если вы ничего не прочитали и просто прокрутили вниз, вы уже получите пользу.
Если вы научитесь программировать, то обойдете сотни тысяч молодых парней и девушек, кто мечтает о высокой зарплате в IT, но хотят только управлять.
Ибо своих любят и признают в любой среде, а если руководитель программиста технически подкован, то это дает +1000 (ИМХО) к скиллу уважения.
Но, по исследованиям, к авторитетам лучше прислушиваются.
Приложу хорошую ссылку (еще еще одна) и ролик выдающихся и известных людей, почему вам стоит научиться программировать.
В комментариях предлагаю поделиться вашими находками из опыта, какими-то кейсами, которые считаете интересными.
