Comments 250
Понеслась…
В итоге остается 8 причин не быть управленцем
Лично меня очень сильно удручает, что в наше время все стараются становится управленцами, а не делать что-либо хорошо, причём это в любой области. И обычно это приводит к подобнычм историям. Потому управленцы конечно нужны, но они должны появлятся там где действительно нужно, а не стремиться становиться управленцем ради повышения зарплаты или там каких-то причин (в этом тезисе я могу заблуждаться, но я вижу это именно так).
P.S. крайне неверно что у управленцев зарплата больше специалистов, учитывая что их знания не устаревают и не требуют постоянного самосовершенствования оплата их умений должна упираться в какой-то разумный потолок, хехе
P.S. крайне неверно что у управленцев зарплата больше специалистов, учитывая что их знания не устаревают и не требуют постоянного самосовершенствования оплата их умений должна упираться в какой-то разумный потолок, хехе
1. стараться стать управленцем не нужно, это очень сложно и нужно иметь способности
как и программистом, потому что типа АЙТИ модно (С)
согласен, что управленцы должны быть не везде. но я четко обозначил миссию в посте — управленец должен создавать условия для сотрудников, чтобы им ничто не мешало работать результативно. а ЗП, административ, планирование, бонусы, мотивация, управление коммуникациями, управление рисками и кучу других вещей нужно делать, и это менеджер проектов. программист не должен думать об этих «мелочах», но без этих «мелочей» очень трудно. каждый, кто был фрилансером, знает, что такое общение с заказчиками, бухгалтерия и тд -и это должен кто-то делать :)
2. риски и ответственность, а также уровень профессионализма рулят. и, конечно, экономический эффект от работы.
если вы — крутой архитектор 100 000 серверов Гугла и управляете как технический лидер подчиненными, ваша ЗП будет не меньше рядового управленца, а в разы больше.
короче, нужно прокачивать профессионализм, и можно будет получать большие деньги везде — хоть программистом, хоть управленцем — и найти себе фирму по вкусу. а дилетанты везде зарабатывают не так много.
рулят профессионалы. 200 000 строк кода без единой ошибки в Тойоте — я думаю, программеры и архитекторы там тоже намазывают хлеб с икрой, не меньше чем менеджеры проекта.
как и программистом, потому что типа АЙТИ модно (С)
согласен, что управленцы должны быть не везде. но я четко обозначил миссию в посте — управленец должен создавать условия для сотрудников, чтобы им ничто не мешало работать результативно. а ЗП, административ, планирование, бонусы, мотивация, управление коммуникациями, управление рисками и кучу других вещей нужно делать, и это менеджер проектов. программист не должен думать об этих «мелочах», но без этих «мелочей» очень трудно. каждый, кто был фрилансером, знает, что такое общение с заказчиками, бухгалтерия и тд -и это должен кто-то делать :)
2. риски и ответственность, а также уровень профессионализма рулят. и, конечно, экономический эффект от работы.
если вы — крутой архитектор 100 000 серверов Гугла и управляете как технический лидер подчиненными, ваша ЗП будет не меньше рядового управленца, а в разы больше.
короче, нужно прокачивать профессионализм, и можно будет получать большие деньги везде — хоть программистом, хоть управленцем — и найти себе фирму по вкусу. а дилетанты везде зарабатывают не так много.
рулят профессионалы. 200 000 строк кода без единой ошибки в Тойоте — я думаю, программеры и архитекторы там тоже намазывают хлеб с икрой, не меньше чем менеджеры проекта.
Проблема не в том, чтобы найти причины стать управленцем, а в том, что реально компетентных управленцев весьма мало и лезет в управленцы очень много шлака. Ибо для того, чтобы стать клевым управленцем большинству требуется прочитать одну клевую книжку от Брукса или Демарко, а чтобы стать всего лишь неплохим программистом нужно перелопатить кучу всего сделать.
И еще: рулят профессионалы ой как не везде. И где это видано, чтобы начальнег получал зп меньше подчиненного?
И еще: рулят профессионалы ой как не везде. И где это видано, чтобы начальнег получал зп меньше подчиненного?
> 200 000 строк кода без единой ошибки
Где об этом можно почитать?
Где об этом можно почитать?
Один раз увидев как начальника отдела увозят с инфарктом, спровоцированным сорванным дедлайном, как-то уже не стремишься и к дедлайнам более ответственно относишься.
Как это ни удивительно, но в некоторых сегментах IT наблюдается именно такая штука. Но при этом таких специалистов стараются держать вне штата — именно как раз по причине кошмарной дороговизны. Например, это консультанты по SAP или iScala
не стремиться становиться управленцем ради повышения зарплаты или там каких-то причинСтремиться надо к тому, чего хочется, и мотивация тут не имеет никакого значения. Иначе всю жизнь будешь себя упрекать в якобы упущенных альтернативах.
Есть реальная история — знакомый (инженер-метролог) решил что хочет быть радиоведущим. Решил и пошел учиться. Заплатил денег, год учился, покрутился в этой тусовке и понял что не его. А если бы не попробовал — в старости обязательно считал бы что не реализовал свою мечту и всё могло бы быть иначе.
по поводу бабла:
1. менеджер получает много не потому, что много знает, а потому, что несет большую ответственность и риски
2. вы сильно недооцениваете, какое количество навыков и опыта нужно иметь грамотному менеджеру для успешной работы
если резюмировать, то специалисту оплачивается ум и усердность, а менеджеру опыт и ответственность.
p.s. вот несколько мыслей по этому поводу cup-of-brand.ru/170211779
1. менеджер получает много не потому, что много знает, а потому, что несет большую ответственность и риски
2. вы сильно недооцениваете, какое количество навыков и опыта нужно иметь грамотному менеджеру для успешной работы
если резюмировать, то специалисту оплачивается ум и усердность, а менеджеру опыт и ответственность.
p.s. вот несколько мыслей по этому поводу cup-of-brand.ru/170211779
Вот объясните мне, как человек с другого берега — какого рода ответственность несёт менеджер? Чем он отвечает, как искупает исправляет свои ошибки?
исправил опечатки
исправил опечатки
в случае факапа проекта обычно с коробочкой в сторону выхода идет менеджер а не программист
Риск быть уволенным, как кажется, нельзя считать таким уже и негативным риском. Проекты не часто меняются. Раз в году может и пойти поискать другую работу.
И вообще, эти ваши менеджерские игры мне не понятны. Менеджер не понимает (часто) ничего в программировании, поэтому не может влиять так как надо на процесс. Суть проблем он только узнает от других, решения принимает на основе предоставленной информации другими. Т.е. в этой «пищевой цепочке» он ничего не производит. В чем тогда опыт? В том, что награда за успешный проект, который он не делал, достается ему, но если проект неуспешный, который он не делал, то его «наказывают». Странно, очень странно.
И вообще, эти ваши менеджерские игры мне не понятны. Менеджер не понимает (часто) ничего в программировании, поэтому не может влиять так как надо на процесс. Суть проблем он только узнает от других, решения принимает на основе предоставленной информации другими. Т.е. в этой «пищевой цепочке» он ничего не производит. В чем тогда опыт? В том, что награда за успешный проект, который он не делал, достается ему, но если проект неуспешный, который он не делал, то его «наказывают». Странно, очень странно.
в этом и соль.
успешный менеджер делает условия для работы, а люди работают сами.
и кажется, что он нихрена не делает.
НО!
как только менеджера нет, то
— то кто-то заболел, и остальные без работы неделю, так как зависели от него, и зависимости разруливал менеджер (верстки нет для сайта). как люди умеют договариваться сами, надеюсь, объяснять не надо. редко когда успешно — гении правда могут, не спорю
— то оба сотрудника ушли в офис и компания в авралах, все упало, сотрудников чинить нет. не учли риски
— программеры ударились в рефакторинг и задержались проект на полгода. он не взлетает — premature optimization. инвесторы в шоке. и программеры потом в шоке, когда проект никому не нужен (см. пост тут про идеальное приложение Архангельского недавно был — 300 штук рублей вложил, и нет успеха. а если бы делал частые релизы — можно было бы вырулить)
— и вообще, набрать лучших из лучших. сначала возьми тимлида, которому доверяешь. потом с его помощью набери толковых программеров. короля играет свита
— и еще миллион вещей
успешный менеджер делает условия для работы, а люди работают сами.
и кажется, что он нихрена не делает.
НО!
как только менеджера нет, то
— то кто-то заболел, и остальные без работы неделю, так как зависели от него, и зависимости разруливал менеджер (верстки нет для сайта). как люди умеют договариваться сами, надеюсь, объяснять не надо. редко когда успешно — гении правда могут, не спорю
— то оба сотрудника ушли в офис и компания в авралах, все упало, сотрудников чинить нет. не учли риски
— программеры ударились в рефакторинг и задержались проект на полгода. он не взлетает — premature optimization. инвесторы в шоке. и программеры потом в шоке, когда проект никому не нужен (см. пост тут про идеальное приложение Архангельского недавно был — 300 штук рублей вложил, и нет успеха. а если бы делал частые релизы — можно было бы вырулить)
— и вообще, набрать лучших из лучших. сначала возьми тимлида, которому доверяешь. потом с его помощью набери толковых программеров. короля играет свита
— и еще миллион вещей
Скорее соглашусь, чем не соглашусь. Со многими но. Грустно всё это — когда программистам нужен кнут для мотивации (и Кнут против premature optimization).
По опыту скажу — лучшие проекты (в срок и сверхнадежные) были, когда не было никаких менеджеров. Людей, правда, тоже мало: 1-3. Почему? Потому что хотя бы когда появляется менеджер, он может убить вопросом: «почему ты покрываешь тестами? Нам за это деньги не платят». Или «кто сказал, что покрытие тестами должно быть 100 процентов?».
Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).
Мотивация у людей сильно растет в случае их личного ощущения причастности и участия в разработке. Всякие аджайлы этому помогают. Чтобы человек не отлынивал, можно, чтобы он сам участвовал в дележе задач. Задачи писать на доске, на стене, возле выхода. Всем видно, кто что делает. Взаимное ревью кода позволяет другим видеть, чем человек занимался, помогает распространять знания о системе (не должно быть — один заболел, от него зависящие бездельничают). ТДД (опять сказал это слово!) позволяет выполнять задачи равномерно, ощущая «на вес» каждый кусок кода — поэтому задачи становятся интересными. Появляется ощущение выполненной работы в любом части проекта.
Несколько хороших опытных программистов — и всё будет в порядке. Единственное, что это бывает в стране единорогов.
Если программисты ударяются в предварительную оптимизацию — факап — неопытные программисты. Если программисты рефакторят полгода — факап — неправильные программисты. Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.
По опыту скажу — лучшие проекты (в срок и сверхнадежные) были, когда не было никаких менеджеров. Людей, правда, тоже мало: 1-3. Почему? Потому что хотя бы когда появляется менеджер, он может убить вопросом: «почему ты покрываешь тестами? Нам за это деньги не платят». Или «кто сказал, что покрытие тестами должно быть 100 процентов?».
Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).
Мотивация у людей сильно растет в случае их личного ощущения причастности и участия в разработке. Всякие аджайлы этому помогают. Чтобы человек не отлынивал, можно, чтобы он сам участвовал в дележе задач. Задачи писать на доске, на стене, возле выхода. Всем видно, кто что делает. Взаимное ревью кода позволяет другим видеть, чем человек занимался, помогает распространять знания о системе (не должно быть — один заболел, от него зависящие бездельничают). ТДД (опять сказал это слово!) позволяет выполнять задачи равномерно, ощущая «на вес» каждый кусок кода — поэтому задачи становятся интересными. Появляется ощущение выполненной работы в любом части проекта.
Несколько хороших опытных программистов — и всё будет в порядке. Единственное, что это бывает в стране единорогов.
Если программисты ударяются в предварительную оптимизацию — факап — неопытные программисты. Если программисты рефакторят полгода — факап — неправильные программисты. Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.
>Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).
если проджект адекватный и есть ведущий программист в группе, то проджект с ведущим это решат
проджект сумеет рассчитать экономический эффект от тестов (очевиден — 0.5 дня против двух * ставки людей за это время + потери необслуженных клиентов) для обоснования времени заказчикам.
а ведущий(=тимлид) будет уверен, что качество ценят, и уверит команду как «свой»
коммуникации рулят.
>Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.
золотые слова!
если проджект адекватный и есть ведущий программист в группе, то проджект с ведущим это решат
проджект сумеет рассчитать экономический эффект от тестов (очевиден — 0.5 дня против двух * ставки людей за это время + потери необслуженных клиентов) для обоснования времени заказчикам.
а ведущий(=тимлид) будет уверен, что качество ценят, и уверит команду как «свой»
коммуникации рулят.
>Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.
золотые слова!
Задача менеджера, в том числе, организовать аджайл процесс (а для начала решить будет аджайл, водопад или ещё что). А главное, менеджер знает цели проекта, грубо говоря, выбирает каким пунктом из «быстро, дешево, качественно» можно пренебречь на данном этапе. Да, он может принимать технические решения (типа будет движок на MySQL или CouchDB) ничего не понимая в них, но он принимает решения, выводящие команду из тупиковых ситуаций, когда половина команды за один вариант, а половина за другой, и вместо работы начинают холиварить.
Несколько хороших, опытных программистов мало, нужен или «выделенный» менеджер, или один из программистов берёт на себя функции менеджера (типа ведущий программист, за которым остаётся последнее слово), организовывая и управляя процессом, принимая и ключевые решения, и текущие. Это хорошо заметно на OpenSource проектах — даже если всё решается голосованием, то кто-то должен принимать решения о форме и процедуре голосования, об «округлении» в спорных случаях, о том кто имеет право голосовать, а кто нет и т. п. — это всё функции менеджера.
Современные системы зачастую используют кучу языков и технологий, в которых одновременно быть экспертом реально только гению. Совместное владение кодом это некий недостижимый идеал. Вернее знать существующий код ещё можно, но быть готовым на лету подхватить разработку в области в которой ты не спеицализируешься без резкого падения скорости и(или) качества сложно, да ещё если эта область тебе не нравится. Живой пример: верстальщик-фронтендер заболел, тебя с серверсайда бросают что-то там допиливать, в принципе ты знаешь, где что у него есть, его код понимаешь, но, например, не знаешь о многообразии плагинов jQuiery и там где он просто взял бы плагин, чутка его подточив, ты начинаешь изобретать велосипед. Изобретаешь-изобретаешь, формально работа идт, потом он выходит, ужасается, стирает нафиг всё что ты написал, и за полчаса прикручивает плагин.
Несколько хороших, опытных программистов мало, нужен или «выделенный» менеджер, или один из программистов берёт на себя функции менеджера (типа ведущий программист, за которым остаётся последнее слово), организовывая и управляя процессом, принимая и ключевые решения, и текущие. Это хорошо заметно на OpenSource проектах — даже если всё решается голосованием, то кто-то должен принимать решения о форме и процедуре голосования, об «округлении» в спорных случаях, о том кто имеет право голосовать, а кто нет и т. п. — это всё функции менеджера.
помогает распространять знания о системе (не должно быть — один заболел, от него зависящие бездельничают)
Современные системы зачастую используют кучу языков и технологий, в которых одновременно быть экспертом реально только гению. Совместное владение кодом это некий недостижимый идеал. Вернее знать существующий код ещё можно, но быть готовым на лету подхватить разработку в области в которой ты не спеицализируешься без резкого падения скорости и(или) качества сложно, да ещё если эта область тебе не нравится. Живой пример: верстальщик-фронтендер заболел, тебя с серверсайда бросают что-то там допиливать, в принципе ты знаешь, где что у него есть, его код понимаешь, но, например, не знаешь о многообразии плагинов jQuiery и там где он просто взял бы плагин, чутка его подточив, ты начинаешь изобретать велосипед. Изобретаешь-изобретаешь, формально работа идт, потом он выходит, ужасается, стирает нафиг всё что ты написал, и за полчаса прикручивает плагин.
А я не говорил или не подразумевал, что не будет программиста, за которым последнее слово. Да, такой человек нужен. Но это один из программистов, который кодит наравне. Он не замыкает на себя информационные каналы, не распределяет задачи, не общается единолично с заказчиком так, как будто бы не холопское это дело другим с ним общаться.
Такой человек нужен для того, чтобы его «не было заметно», а только в критической ситуации дать последнее слово. Но и это вообще-то плохо, чаще всего есть более надежные способы, чем доверять чьему-то мнению. Например, при выборе какой-то технологии, какого-то фреймворка или библиотеки, сначала собираются требования-пожелания от коллектива, потом делаются небольшие исследования, возможно замеры, выносятся на обсуждение плюсы и минусы.
Другое дело — менеджер, который считает, что нужно уметь только менеджить (это из статьи про 13 недостатков). Человек, далекий от разработки и особенно не бывший никогда разработчиком, не может физически принимать адекватные решения по поводу технических вещей. Поэтому когда он принимает, то просто полагается на тех, кому он доверяет — но и таких людей изначально выбрать не может, потому что опять же — нет у него критериев для оценки — кто хороший специалист, а кто нет. Бывали такие ситуации из жизни:
— Вы же специалисты, скажите, что вы думаете об этой проблеме?
Рассказывают. Потом такой менеджер говорит:
— Я думаю, что эту проблему надо решать так:…
(т.е. польза от него нулевая. Даже отрицательная. Потому что программисты бы быстрее договорились между собой, не опускаясь в объяснение того, что знает любой программист, и не опускаясь в детали пересказывания заново работы системы).
Иногда от таких руководителей можно вообще катастрофических решений ожидать, как в этом совещании. Хорошо, когда они хотя бы не мешают, а разделяют ответственность — берут на себя вопросы, которым неинтересно заниматься программистам или это их бы сильно отвлекало. Но при этом доверяют программистам технические вопросы.
Не совсем. Команды нормальные где-то около 4-6 человек (на мой взгляд, исследований таких не читал). Больше людей в одну команду нецелесообразно — и владение кодом тяжелее становится и совещания шумные и кпд низкое. Нижней границы правда нет, может и 1 программист, если справляется с проектом. Команда из 6 опытных программистов может очень многое. Тут смотря что называть серьезным проектом. Не каждая команда пишет эксель или ворд (хотя, думаю, при достаточном времени и 6 человек напишут в реальные сроки). Не каждая команда пишет операционную систему. Для большинства проектов больше людей не нужно. Даже и этих много. Это мое мнение.
Но если всё же случаются проекты, где людей нужно больше, то делятся на такие команды. Каждая команда может успешно делать свой модуль, работать в том же аджайле независимо, иногда договариваясь про API и иногда проводя общие совещания (с другими командами) и есть общий отдел тестирования. Владеть кодом будут люди внутри команды и кодом команды. Этого достаточно, чтобы не быть кому-то незаменимым. Не только ревью кода помогает знать о системе. Можно и успешно меняться местами. Брать разные задачи так, чтобы каждый поучаствовал в каком-то куске.
А с чужим кодом да, будет потеря производительности. Но далеко не катастрофическая, если что-то случится — день два — и человек уже разобрался и может кодить
Такой человек нужен для того, чтобы его «не было заметно», а только в критической ситуации дать последнее слово. Но и это вообще-то плохо, чаще всего есть более надежные способы, чем доверять чьему-то мнению. Например, при выборе какой-то технологии, какого-то фреймворка или библиотеки, сначала собираются требования-пожелания от коллектива, потом делаются небольшие исследования, возможно замеры, выносятся на обсуждение плюсы и минусы.
Другое дело — менеджер, который считает, что нужно уметь только менеджить (это из статьи про 13 недостатков). Человек, далекий от разработки и особенно не бывший никогда разработчиком, не может физически принимать адекватные решения по поводу технических вещей. Поэтому когда он принимает, то просто полагается на тех, кому он доверяет — но и таких людей изначально выбрать не может, потому что опять же — нет у него критериев для оценки — кто хороший специалист, а кто нет. Бывали такие ситуации из жизни:
— Вы же специалисты, скажите, что вы думаете об этой проблеме?
Рассказывают. Потом такой менеджер говорит:
— Я думаю, что эту проблему надо решать так:…
(т.е. польза от него нулевая. Даже отрицательная. Потому что программисты бы быстрее договорились между собой, не опускаясь в объяснение того, что знает любой программист, и не опускаясь в детали пересказывания заново работы системы).
Иногда от таких руководителей можно вообще катастрофических решений ожидать, как в этом совещании. Хорошо, когда они хотя бы не мешают, а разделяют ответственность — берут на себя вопросы, которым неинтересно заниматься программистам или это их бы сильно отвлекало. Но при этом доверяют программистам технические вопросы.
Современные системы зачастую используют кучу языков и технологий, в которых одновременно быть экспертом реально только гению. Совместное владение кодом это некий недостижимый идеал.
Не совсем. Команды нормальные где-то около 4-6 человек (на мой взгляд, исследований таких не читал). Больше людей в одну команду нецелесообразно — и владение кодом тяжелее становится и совещания шумные и кпд низкое. Нижней границы правда нет, может и 1 программист, если справляется с проектом. Команда из 6 опытных программистов может очень многое. Тут смотря что называть серьезным проектом. Не каждая команда пишет эксель или ворд (хотя, думаю, при достаточном времени и 6 человек напишут в реальные сроки). Не каждая команда пишет операционную систему. Для большинства проектов больше людей не нужно. Даже и этих много. Это мое мнение.
Но если всё же случаются проекты, где людей нужно больше, то делятся на такие команды. Каждая команда может успешно делать свой модуль, работать в том же аджайле независимо, иногда договариваясь про API и иногда проводя общие совещания (с другими командами) и есть общий отдел тестирования. Владеть кодом будут люди внутри команды и кодом команды. Этого достаточно, чтобы не быть кому-то незаменимым. Не только ревью кода помогает знать о системе. Можно и успешно меняться местами. Брать разные задачи так, чтобы каждый поучаствовал в каком-то куске.
А с чужим кодом да, будет потеря производительности. Но далеко не катастрофическая, если что-то случится — день два — и человек уже разобрался и может кодить
Если за ним последнее слово, то он будет распределять задачи так или иначе — задачи, за которые никто не хочет браться, или задачи за которые хотят браться все, или задачи за который один человек хочет взяться, но он работает уже над не менее важной задачей и передавать её не рационально. Заказчики сами зачастую предпочитают общаться с одним человеком, особенно если только один человек из команды может говорить с ними на языке бизнеса этого заказчика.
Замеры, плюсы-минусы, обсуждения и т. п. — это всё хорошо, но должен быть кто-то кто скажет «мы посовещались и я решил».
Угу, дизайнер, верстальщик, фронтендер, серверсайдер, админ. Да, все они владеют кодом (и не только), да, все они могут какой-то простой баг типа опечатки по-быстрому поправить. Но целесообразно ли админа сажать за оптимизацию вёрстки или дизайнера за кэширование на уровне приложения?
Замеры, плюсы-минусы, обсуждения и т. п. — это всё хорошо, но должен быть кто-то кто скажет «мы посовещались и я решил».
Не совсем. Команды нормальные где-то около 4-6 человек
Угу, дизайнер, верстальщик, фронтендер, серверсайдер, админ. Да, все они владеют кодом (и не только), да, все они могут какой-то простой баг типа опечатки по-быстрому поправить. Но целесообразно ли админа сажать за оптимизацию вёрстки или дизайнера за кэширование на уровне приложения?
А с чего вдруг будут такие задачи, за которые никто браться не хочет? Владение кодом то общее. А поэтому с необходимостью кодом меняются. И код пишут по очереди в разных местах. А то еще возьмется за неинтересную задачу кто-то, а потом ревьювить будет тоже всем неинтересно.
Я в таких идеальных коллективах не работал, чтобы и кодом менялись и все были опытные сразу. Хотя в той или иной степени всегда где-то в гибких разработках участвовал. Но люди делятся опытом, рассказывают, что при таком подходе вдруг у всех включается интерес и ответственность. И кого-то подгонять или заставлять делать то, что «неинтересно» не надо. Это нужно проекту? Да. Так почему же это неинтересно? Рутина? Так где-же наши умения ее сокращать? Это тоже интересно.
Задачи любые интересны, если используется какой-то «системных подход» к их решению, ТДД (опять это слово!).
«дизайнер, верстальщик, фронтендер, серверсайдер, админ» — это не из расы программистов. Я про них не говорил. Понятно, что кодом владеют только программисты. По крайней мере править код могут только и только они. А вот, в среде именно программистов — никаких секретов.
Я в таких идеальных коллективах не работал, чтобы и кодом менялись и все были опытные сразу. Хотя в той или иной степени всегда где-то в гибких разработках участвовал. Но люди делятся опытом, рассказывают, что при таком подходе вдруг у всех включается интерес и ответственность. И кого-то подгонять или заставлять делать то, что «неинтересно» не надо. Это нужно проекту? Да. Так почему же это неинтересно? Рутина? Так где-же наши умения ее сокращать? Это тоже интересно.
Задачи любые интересны, если используется какой-то «системных подход» к их решению, ТДД (опять это слово!).
«дизайнер, верстальщик, фронтендер, серверсайдер, админ» — это не из расы программистов. Я про них не говорил. Понятно, что кодом владеют только программисты. По крайней мере править код могут только и только они. А вот, в среде именно программистов — никаких секретов.
Ошибся в копипасте. фронтендер, серверсайдер — программисты. Лично я против такого деления. И сервер-сайд и фронтэнд — пусть пишут одни и те же люди
Верстальщик тоже пишет код (html/css) который прямо присутствует в коде проекта, более того фронтендер и серверсайдер непосредственно с этим кодом взаимодействуют. Они втроем правят одни и те же файлы. Они совместно владеют кодом и, как правило, понимают весь код в этих файлах и могут по мелочам поправить код вне зоны своей специализации.
Ладно, пускай два программиста с примерно одинаковым бэкграундом, но одному нравится писать модели, реализовывать бизнес-логику, другому нравится визуализировать данные на клиенте, а вот писать контроллеры и прочую логику приложения (аутентификацию и авторизацию, валидацию и санацию, хранение и кэширование и т. п.), не нравится никому. Но без этого никак, все это понимают, но никто делать не хочет.
А с чего вдруг будут такие задачи, за которые никто браться не хочет?
Ладно, пускай два программиста с примерно одинаковым бэкграундом, но одному нравится писать модели, реализовывать бизнес-логику, другому нравится визуализировать данные на клиенте, а вот писать контроллеры и прочую логику приложения (аутентификацию и авторизацию, валидацию и санацию, хранение и кэширование и т. п.), не нравится никому. Но без этого никак, все это понимают, но никто делать не хочет.
Если менеджер нифига не понимает в предметной области, значит компания зажала денег на качественного менеджера. В Гугле, например, практически нереально стать продакт менеджером без первоначального диплома в computer science. Не в экономике, а именно в ИТ, потому что откуда иначе ты будешь знать как создавать софтверные продукты?
То же самое в любой другой области, без соответствующего опыта или знаний не возьмут.
А риск быть уволенным и не получить хороших рекомендаций — это большой риск. Потому что на интервью тебя спросят, чем ты раньше занимался и какие были последние проекты. И на каком-нибудь узком рынке найти знакомых знакомых и проверить, не зафакапил ли проекты данный человек — проще простого. Это программиста посадил, он тебе написал код, и дальше особо ходить не надо. А людей на управленческие позиции часто ищут по рекомендациям и проверяют как могут.
То же самое в любой другой области, без соответствующего опыта или знаний не возьмут.
А риск быть уволенным и не получить хороших рекомендаций — это большой риск. Потому что на интервью тебя спросят, чем ты раньше занимался и какие были последние проекты. И на каком-нибудь узком рынке найти знакомых знакомых и проверить, не зафакапил ли проекты данный человек — проще простого. Это программиста посадил, он тебе написал код, и дальше особо ходить не надо. А людей на управленческие позиции часто ищут по рекомендациям и проверяют как могут.
Это программиста посадил, он тебе написал код, и дальше особо ходить не надо
Этого программиста сначала надо найти, которого можно посадит, и он напишет в срок код, который потом не придётся 100 раз переписать. И найти его сложнее чем менеджера, да и без менеджера конечный продукт может иметь место, а без программиста нет, так что мне кажется, что вы очень преувеличиваете роль менеджера в разработке ПО.
А про риски быть уволенным — все сотрудники компании имеют риск быть уволенными без рекоммендаций и у всех достаточно несложно проверить.
Я речь вела про интервью :) Дал задание, и сразу видно, может человек писать код или нет. Не нужно искать людей через третьи руки, которые с ним работали, чтобы выяснить, правда ли он кодил хорошо.
Да, хорошего специалиста непросто найти, но это можно сказать про специалиста в любой области, их везде мало.
Я не преувеличиваю роль менеджера в разработке ПО, просто надо сравнивать большие проекты, где есть насущная потребность в менеджменте, а не маленькие группы разработчиков, где вполне работает самоорганизация. Проекты, где много хороших программистов, но в результате делается не тот продукт что заказывали, не в те сроки или с трехразовым перерасходом бюджета я видела. Почему-то никто за этот продукт платить не хотел в результате, хотя каждый отдельно взятый программист — душка и зайка (разве что звереет от регулярного общения с клиентом напрямую)).
Да, хорошего специалиста непросто найти, но это можно сказать про специалиста в любой области, их везде мало.
Я не преувеличиваю роль менеджера в разработке ПО, просто надо сравнивать большие проекты, где есть насущная потребность в менеджменте, а не маленькие группы разработчиков, где вполне работает самоорганизация. Проекты, где много хороших программистов, но в результате делается не тот продукт что заказывали, не в те сроки или с трехразовым перерасходом бюджета я видела. Почему-то никто за этот продукт платить не хотел в результате, хотя каждый отдельно взятый программист — душка и зайка (разве что звереет от регулярного общения с клиентом напрямую)).
Спасибо, а как менеджеры исправляют допущенные ошибки?
Да, я правильно вас понял, что в случае проблем менеджер увольняется, а программисты остаются решать эти проблемы?
я уже приводил выше.
1. если выбрал не ту стратегию — маркетинговую, продажи и ценообразование, не тот интерфейс утвердил, не те user stories И тд — то программист сделал и сдал по ТЗ и свободен.
а бюджет проекта ушел в минуса. и менеджер не получил денег
2. кто-то заболел, кто-то не сдал работу в срок.
опять же, менеджер не получил бонус (часто существенная часть дохода). а человек свою зарплату получил и не парится
3. что-то упало ночью. вы встали и нередко сами чините, либо некоторых спецов дергаете. основная часть штата не знает об этом и спит спокойно.
4. вы овертаймите, потому что очень много параллельных задач плюс неучтенные риски (=тоже ваш косяк)
сотрудники же работают 10-19.
и так далее
1. если выбрал не ту стратегию — маркетинговую, продажи и ценообразование, не тот интерфейс утвердил, не те user stories И тд — то программист сделал и сдал по ТЗ и свободен.
а бюджет проекта ушел в минуса. и менеджер не получил денег
2. кто-то заболел, кто-то не сдал работу в срок.
опять же, менеджер не получил бонус (часто существенная часть дохода). а человек свою зарплату получил и не парится
3. что-то упало ночью. вы встали и нередко сами чините, либо некоторых спецов дергаете. основная часть штата не знает об этом и спит спокойно.
4. вы овертаймите, потому что очень много параллельных задач плюс неучтенные риски (=тоже ваш косяк)
сотрудники же работают 10-19.
и так далее
«Управленческая наделя» на Хабре?
Устраиваюсь поудобнее :)
Устраиваюсь поудобнее :)
я уже раз 5 порывался ответы написать на такие посты.
сегодня созрел
сегодня созрел
На мой взгляд, статья, на которую вы отвечаете, была заметно лучше тем, что была ближе к жизни. В ней автор говорил не только об общих вопросах, как здесь, но и ежедневной рутине, которая как раз формирует отношение к профессии.
А есть ли в ежедневной практике вещи, которые вам не нравились, как программисту, и которых нет в менеджерстве?
А есть ли в ежедневной практике вещи, которые вам не нравились, как программисту, и которых нет в менеджерстве?
я бы мог добавить, но объем вырастет в 2-3 раза.
поленился, буду честен.
вещей не нравилось много
1. это постоянный результат, каждый день много нужно делать, и если заболел — труба, результат не выдается. просто программирование — это процесс творческий, можно делать бесконечно, и круто рефакторить неделю архитектуру под SOLID, разруливать ответственности. или тюнить производительность.
а бизнес требовал результатов, и разочаровываешься — вроде работает, но неидеально, а улучшить особо некогда. нужно делать новый продукт :)
в управлении я могу варьировать свою нагрузку более плавно, больше свободы. неделю отдыхаем, рефакторим, я тестирую проекты, пишу программы развития отдела. потом впахиваем, делаем релиз, внедряем. потом снова отдых.
2. поднадоело. я как программист чуть выше среднего, брал упорством и трудом.
спустя 10 лет (я программлю с 13, как многие тут) уже не прет от новых языков или задач. был и софт, и базы, и шифраторы я писал, были и дипломы разные за программки прикладные, и за веб-сайты благодарности.
сейчас берешь задачу, думаешь час-два-максимум неделю. получаешь решение на бумаге, или рабочий прототип. а дальше все ясно, и уже скучно.
условно, я пишу на интуиции. много читал и изучал, и решение задачи выглядит так. долго думаешь, и так и сяк, а потом раз — и готово решение. и оно предсказуемо 100%, заработает, только пиши код 2-3 недели.
а в управлении вещи другого порядка. тут думаешь, как пользователю сделать удобнее, вживаешься в его шкуру. измеряешь посещаемость раздела на сайте, думаешь, как ее поднять. как повысить монетизацию продукта, чтобы клиенту было полезно. и каждый раз что-то новое. нет универсальных решений.
допускаю, через 10 лет опять буду прогать. не знаю :)
поленился, буду честен.
вещей не нравилось много
1. это постоянный результат, каждый день много нужно делать, и если заболел — труба, результат не выдается. просто программирование — это процесс творческий, можно делать бесконечно, и круто рефакторить неделю архитектуру под SOLID, разруливать ответственности. или тюнить производительность.
а бизнес требовал результатов, и разочаровываешься — вроде работает, но неидеально, а улучшить особо некогда. нужно делать новый продукт :)
в управлении я могу варьировать свою нагрузку более плавно, больше свободы. неделю отдыхаем, рефакторим, я тестирую проекты, пишу программы развития отдела. потом впахиваем, делаем релиз, внедряем. потом снова отдых.
2. поднадоело. я как программист чуть выше среднего, брал упорством и трудом.
спустя 10 лет (я программлю с 13, как многие тут) уже не прет от новых языков или задач. был и софт, и базы, и шифраторы я писал, были и дипломы разные за программки прикладные, и за веб-сайты благодарности.
сейчас берешь задачу, думаешь час-два-максимум неделю. получаешь решение на бумаге, или рабочий прототип. а дальше все ясно, и уже скучно.
условно, я пишу на интуиции. много читал и изучал, и решение задачи выглядит так. долго думаешь, и так и сяк, а потом раз — и готово решение. и оно предсказуемо 100%, заработает, только пиши код 2-3 недели.
а в управлении вещи другого порядка. тут думаешь, как пользователю сделать удобнее, вживаешься в его шкуру. измеряешь посещаемость раздела на сайте, думаешь, как ее поднять. как повысить монетизацию продукта, чтобы клиенту было полезно. и каждый раз что-то новое. нет универсальных решений.
допускаю, через 10 лет опять буду прогать. не знаю :)
Так в реальной жизни (читай в бизнесе) нет особо сложных задач. Ну т.е. они с другой стороны не тривиальные, но это скорее от индивидуальности каждой отрасли и компании.
Управлять такими темпами тоже станет скучно. Одни и те же косяки сотрудников, одни и те же совещания. И вроде обсуждаете по теме, а ощущение, что где-то это уже было.
ИМХО никогда не будет скучно только в науке. Тут может попасться задачка, что на всю жизнь хватит и внукам еще останется.
Управлять такими темпами тоже станет скучно. Одни и те же косяки сотрудников, одни и те же совещания. И вроде обсуждаете по теме, а ощущение, что где-то это уже было.
ИМХО никогда не будет скучно только в науке. Тут может попасться задачка, что на всю жизнь хватит и внукам еще останется.
Мне пока в новинку.
И потом, я занимаюсь автоматизацией внутри компании.
Это, считайте, стартапы в разных сферах. Очень сложно и достаточно интересно.
Недавно делали отдел обучения новичков. Сейчас делаем обучение существующих сотрудников.
Очень круто — можно взять любой проект, отдел, бизнес-процесс и улучшить. Новая сфера, новые знания, новые люди, новые клиенты!
И потом, я занимаюсь автоматизацией внутри компании.
Это, считайте, стартапы в разных сферах. Очень сложно и достаточно интересно.
Недавно делали отдел обучения новичков. Сейчас делаем обучение существующих сотрудников.
Очень круто — можно взять любой проект, отдел, бизнес-процесс и улучшить. Новая сфера, новые знания, новые люди, новые клиенты!
И кстати, лично я программирую 17 лет (с 8). И как-то не надоело. Даже в каком-то смысле открылось второе дыхание.
Расписал подробнее пункты.
Ваш оппонент более убедителен. его пост пропитан опытом, а это просто вырезка и вступления к какой нибудь брошюрке курсов для манагеров. Стоило бы получше подготовится, а не бросаться писать опровержение.
Вот, сразу видно разницу между настоящим интровертом (много деталей, много связей, в т.ч. между пунктами, все взаимосвязано и довольно подробно) и экстравертом (возмутился другой точке зрения, кратко накидал список атрибутов — не связей — и типо все).
П.с. имхо, если программист перестаёт видеть сложность в своих задачах и абсолютно уверен в том, что напланированная задача будет успешно решена, по-сути, ещё до написания кода — он, скорее всего, засиделся на простых задачах. В общем п.3 несколько притянут за уши.
П.с. имхо, если программист перестаёт видеть сложность в своих задачах и абсолютно уверен в том, что напланированная задача будет успешно решена, по-сути, ещё до написания кода — он, скорее всего, засиделся на простых задачах. В общем п.3 несколько притянут за уши.
я обычно пишу большие посты по управлению (см. блог), с деталями и примерами.
часов 4-5 занимает.
тут задача была сделать прототип поста. может, он не понравится Хабралюдям. и тогда 4-5 часов пойдут под хвост.
на каждый пункт могу добавить много примеров, если будет много запросов в комментариях.
часов 4-5 занимает.
тут задача была сделать прототип поста. может, он не понравится Хабралюдям. и тогда 4-5 часов пойдут под хвост.
на каждый пункт могу добавить много примеров, если будет много запросов в комментариях.
Мне кажется, что то, что вы написали не имеет отношения к дихотомии экстраверт-интроверт. Вполне можно быть поверхностным интровертом, и глубококопающим экстравертом.
А вообще, как в анекдоте — мамы всякие важны, мамы всякие нужны. Важно понять, что ближе конкретном человеку, и не мучаться, занимаясь чуждым делом.
А вообще, как в анекдоте — мамы всякие важны, мамы всякие нужны. Важно понять, что ближе конкретном человеку, и не мучаться, занимаясь чуждым делом.
кстати я с людьми обычно замкнут. хотя умею знакомиться со случайными и заводить отношения, но не люблю это делать.
но в работе эмоционален и экспрессивен. и пою на сцене тоже (это хобби)
www.youtube.com/watch?v=vGtJgMY0hrg
так что то ли интроверт, то ли экстраверт, фиг его поймет. «я был посредственный поэт, зато отличный гражданин» (С) в роли Сталина «Гражданин поэт»
но в работе эмоционален и экспрессивен. и пою на сцене тоже (это хобби)
www.youtube.com/watch?v=vGtJgMY0hrg
так что то ли интроверт, то ли экстраверт, фиг его поймет. «я был посредственный поэт, зато отличный гражданин» (С) в роли Сталина «Гражданин поэт»
У меня примерно так же с контактами вне работы.
Я думаю, что умение грамотной коммуникации не связано с интро- или экстровертностью — это просто один из навыков, который можно развить. Предрасположенность конечно разная, но мне кажется, что даже самый нелюдимый и мизантропичный интроверт когда-нибудь поймет, что отгородится от всего мира не получится, и придется находить общий язык с теми людьми, с которыми работаешь.
К тому же это в равной степени касается как манагера, так и специалиста.
P.S. Вы потрясающе поете. Огромный респект!
Я думаю, что умение грамотной коммуникации не связано с интро- или экстровертностью — это просто один из навыков, который можно развить. Предрасположенность конечно разная, но мне кажется, что даже самый нелюдимый и мизантропичный интроверт когда-нибудь поймет, что отгородится от всего мира не получится, и придется находить общий язык с теми людьми, с которыми работаешь.
К тому же это в равной степени касается как манагера, так и специалиста.
P.S. Вы потрясающе поете. Огромный респект!
См. Коммент к ветке чуть ниже. Судя по построению речи вы более экстраверт. Неудержимого желания общаться со всеми и постоянно это не будет означать.
ок спс.
сложно сказать. я бы отметил, что это два режима мышления.
когда я проектирую систему, сначала я «нормализую» ее. выделяю ключевые сущности, элементы, объекты. что в проекте, что в архитектуре системы (ООП).
дальше — связи между ними и их состояниями. диаграмма последовательностей в UML, user stories если это в проекте.
есть еще много режимов мышления, я стараюсь применять тот, который нужен в ситуации.
это оно?
сложно сказать. я бы отметил, что это два режима мышления.
когда я проектирую систему, сначала я «нормализую» ее. выделяю ключевые сущности, элементы, объекты. что в проекте, что в архитектуре системы (ООП).
дальше — связи между ними и их состояниями. диаграмма последовательностей в UML, user stories если это в проекте.
есть еще много режимов мышления, я стараюсь применять тот, который нужен в ситуации.
это оно?
Как любая абстракция «про людей», в совсем чистом виде ничего не встречается ;) А так да, похоже не правду. Характерной особенностью так же может быть возможность без напряжения помнить обо всем и всех понемногу, не вдаваясь в подробности — но о многом.
У меня при построении систем наоборот, собственно определить сущности/состояния — самая муторная часть. Зато взаимосвязи строятся разве что не сами, нормализация РБД для меня вообще шоком была «а разве можно делать сначала как-то не так?!»
У меня при построении систем наоборот, собственно определить сущности/состояния — самая муторная часть. Зато взаимосвязи строятся разве что не сами, нормализация РБД для меня вообще шоком была «а разве можно делать сначала как-то не так?!»
П.с. вообще это про себя нужно знать для одно важной штуки — как правильно ставить задачи. Экстраверты стремятся к цели, к ещё конкретному достижению, интроверты стремятся просто идти в правильном направлении. Примерно по этой причине хороший менеджер сумеет назвать правильный срок даже если его программисты этот срок назовут довольно расплывчато, а сами программисты такие навыки часто приобретают только с достаточным опытом.
А «глубоко» — это как?
По Юнгу экстраверт — это человек, который видит состояния и объекты, а интроверт — связи между объектами и состояниями. Скорее ложно понимание интровертов как нелюдимых молчунов, а экстравертов как компанейских людей. Это просто следствия изначального восприятия, статистически удобная форма личности.
По Юнгу экстраверт — это человек, который видит состояния и объекты, а интроверт — связи между объектами и состояниями. Скорее ложно понимание интровертов как нелюдимых молчунов, а экстравертов как компанейских людей. Это просто следствия изначального восприятия, статистически удобная форма личности.
В 90-х активно интересовался менеджментом, вплоть до добровольных двух курсов ВО после ухода из техвуза, куда родители «запихали». Но когда понял, что менеджмент это прежде всего работа с людьми, а не экономика, финансы, логистика, трейдинг и прочие формальные (или кажущиеся таковыми :) системы, то решил держаться от него подальше, пока психологию человека не разложат на формулы. Прочитав оба поста обрадовался — всё правильно сделал :)
Мне кажется, что наиболее адекватная мотивация в том, чтобы быть менеджером — это желание сделать нечто такое, что один человек сделать не может в принципе.
Попытаюсь проиллюстрировать примером. Пусть вам в голову пришла идея некоего приложения. Вы научились писать приложения, рисовать графику, и написали свою софтину. Сложно, но — вполне возможно. Хотя есть немало примеров, когда такой кейс является неподъемным для одного человека, возникает команда, которой требуется один человек, который будет направлять творческие усилия в осмысленное русло.
А теперь представьте, что вы решили сделать революционный супер-пупер ноутбук. Или планшет. Да что уж там — хотя бы клавиатуру. Вы правда представляете, что сможете сделать все сами? Начиная с разработки и заканчивая производством и сбытом?
Хороший руководитель обязан мыслить стратегически и масштабно. Если же единственное, чем занимается менеджер — это подготовкой отчетов и бессмысленной муштрой своих подчиненных — то это не менеджер, это кошмарное недоразумение, которое зря получает свою зарплату.
Попытаюсь проиллюстрировать примером. Пусть вам в голову пришла идея некоего приложения. Вы научились писать приложения, рисовать графику, и написали свою софтину. Сложно, но — вполне возможно. Хотя есть немало примеров, когда такой кейс является неподъемным для одного человека, возникает команда, которой требуется один человек, который будет направлять творческие усилия в осмысленное русло.
А теперь представьте, что вы решили сделать революционный супер-пупер ноутбук. Или планшет. Да что уж там — хотя бы клавиатуру. Вы правда представляете, что сможете сделать все сами? Начиная с разработки и заканчивая производством и сбытом?
Хороший руководитель обязан мыслить стратегически и масштабно. Если же единственное, чем занимается менеджер — это подготовкой отчетов и бессмысленной муштрой своих подчиненных — то это не менеджер, это кошмарное недоразумение, которое зря получает свою зарплату.
Мне кажется, что наиболее адекватная мотивация в том, чтобы быть менеджером — это желание сделать нечто такое, что один человек сделать не может в принципе.
Отличная формулировка, поклон за точность!
Отличная формулировка, поклон за точность!
Почему-то кажется, что таких менеджеров либо вообще нету, либо их меньше 1% и мне с ними не посчастливилось встретиться.
Как минимум в нашей стране любая управляющая должность считается заведомо лучше любой другой профессии. Скажем слесарь всегда почему-то хуже бригадира (я немного утрирую, думаю понятно). Поэтому многие хорошие программисты становятся менеджерами (потому что жена пилит, потому что денег больше и т д), а не потому, что <ваша цитата>.
А потому конечно они будут плакать, что работа сложная, никакой отдачи, то плохо это плохо.
Ну вот если бы программист мог так же перейти скажем работать терапевтом в поликлинику. Я думаю опять же многие заплакали бы на тему (вот старухи ходят, одно и то же каждый день и т д). А ведь у врачей на самом деле точно такие же крутые задачи есть. И точно такая же текучка, которую кто-то должен делать.
Люди, меняйте отношение к работе. Работа не для денег, она для души.
Как минимум в нашей стране любая управляющая должность считается заведомо лучше любой другой профессии. Скажем слесарь всегда почему-то хуже бригадира (я немного утрирую, думаю понятно). Поэтому многие хорошие программисты становятся менеджерами (потому что жена пилит, потому что денег больше и т д), а не потому, что <ваша цитата>.
А потому конечно они будут плакать, что работа сложная, никакой отдачи, то плохо это плохо.
Ну вот если бы программист мог так же перейти скажем работать терапевтом в поликлинику. Я думаю опять же многие заплакали бы на тему (вот старухи ходят, одно и то же каждый день и т д). А ведь у врачей на самом деле точно такие же крутые задачи есть. И точно такая же текучка, которую кто-то должен делать.
Люди, меняйте отношение к работе. Работа не для денег, она для души.
Ну мне поднадоело немного программить. При этом я учусь управлять и меня это прет. Одно из — то, что вы написали. Пусть как управленца меня оценивают другие, тут еще вагон и маленькая тележка работы предстоит.
Я горд своими программистами. Они профессионалы, многие любят работу. И пусть работают, они оживляют проект, собственно, делают много работы, творят, думают. Я же сам программист, понимаю, как это трудно. Зачем им рваться управлять?
И никакой управленец не работает без команды, рулят профессионалы — исполнители.
Даешь каждому свое дело по душе!
Я горд своими программистами. Они профессионалы, многие любят работу. И пусть работают, они оживляют проект, собственно, делают много работы, творят, думают. Я же сам программист, понимаю, как это трудно. Зачем им рваться управлять?
И никакой управленец не работает без команды, рулят профессионалы — исполнители.
Даешь каждому свое дело по душе!
Все меняется когда приходит Идея. И ты понимаешь что в одиночку ее не осуществить.
К счастью я умею определить предрасположенность людей к той или иной работе, поэтому собрать команду по сути не сложно. По началу было не привычно. Нанимаешь людей отдаешь приказы. И начинаешь медленно офигевать… то на что сам бы потратил месяц-два, а то и три решается за неделю. И вот тут просыпается азарт. Ты можешь сконцентрироваться на выпуске какого либо продукта или услуги. Окружив себя умными людьми — можно смело делегировать целые задачи, и не боятся что они не будут исполнены.
Я когда впервые занял позицию менеджера, в одном из проектов, и когда через 3 недели мы выдали ощутимый результат… (сам так же занимался программированием частично, но и команду удалось собрать практически идеальную)… Это не описать словами… кайф. Это не просто мотивирует, это фантастично =)
К счастью я умею определить предрасположенность людей к той или иной работе, поэтому собрать команду по сути не сложно. По началу было не привычно. Нанимаешь людей отдаешь приказы. И начинаешь медленно офигевать… то на что сам бы потратил месяц-два, а то и три решается за неделю. И вот тут просыпается азарт. Ты можешь сконцентрироваться на выпуске какого либо продукта или услуги. Окружив себя умными людьми — можно смело делегировать целые задачи, и не боятся что они не будут исполнены.
Я когда впервые занял позицию менеджера, в одном из проектов, и когда через 3 недели мы выдали ощутимый результат… (сам так же занимался программированием частично, но и команду удалось собрать практически идеальную)… Это не описать словами… кайф. Это не просто мотивирует, это фантастично =)
А куда в этой формуле давать «среднее звено»? Такие люди могут любить своё дело, но возможности реализовать собственно свои задумки у них может не быть — есть планы, есть задания вышестоящих. И без них ведь тоже никуда.
А где вы там нашли «свои задумки», там абстрактное «нечто». Есть задание вышестоящих, которое один человек выполнить не может — типичный вызов медеджеру, сможет ли он организовать процесс так, чтобы задание было выполнено или не сможет, а в идеале выполнено досрочно, меньшими ресурсам, но не в ущерб качеству. Если вы такое задание воспринимаете как вызов, то сочувствую :) — вы менеджер в душе.
Мда, видимо плохо соображалось ночью)
Воспринимаю так почти все, но чур меня — это просто качество человека, хотя бы старающегося быть ответственным))
Воспринимаю так почти все, но чур меня — это просто качество человека, хотя бы старающегося быть ответственным))
Не в ответственности дело. Лично для меня вызов написать какой-то сложный модуль, отрефакторить код десятилетней давности, продумать архитектуру или схему БД и т. п.: получится в срок — я крут, не получится — ну облажался, с кем не бывает на сложных задачах. А вот делегировать задачи и ответственность — это для меня просто наказание. Если получится — это сделал не я, а подчиненные, если не получится — облажался я: никакой положительной мотивации в решении таких задач не вижу. Единственный вариант с положительной мотивацией — делать самому работу рассчитанную на, скажем, троих, работая по 16-18 часов в сутки без выходных, но надолго меня в таком режиме не хватает — месяц-другой и если не успел проект закончить, то всё, дедлайн сорван, а если успел то опуск нужен хотя бы дней 10…
Насчет сложностей с делегированием, переработками и мотивацией — это все знакомо. ИМХО это все дело привычки и наличия какого-то способа передать ответственность без необходимости убеждать/уговаривать/упрашивать.
В нашей маленькой компании как раз идет процесс слаживания команды, мне каккрайнему веб-девелоперу приходится так же крутиться «за троих». Но на последних проектах я понял, что задачи или какие-то сложности по верстке проще/быстрее/надежнее передать нашему штатному верстальщику, чем решать самому — во-первых часть вопросов действительно решится сильно быстрее, во-вторых дел даже просто так у меня на пару месяцев вперед распланировано — так что любая параллельность хороша, даже если она где-то по началу не супер-эффективна.
Как только эта привычка к восприятию делегирования сломана — остается все тот же процесс по набиванию скилла — выяснение всяких плюшек и приемов, понимание взаимосвязей и проблемных мест — все наше родное. Детерминированности, конечно, меньше, но, думаю, любой программист встречал баги запредельной для текущего уровня понимания сложности на ровном месте. Принципиальной разницы между этими ситуациями просто не вижу.
В нашей маленькой компании как раз идет процесс слаживания команды, мне как
Как только эта привычка к восприятию делегирования сломана — остается все тот же процесс по набиванию скилла — выяснение всяких плюшек и приемов, понимание взаимосвязей и проблемных мест — все наше родное. Детерминированности, конечно, меньше, но, думаю, любой программист встречал баги запредельной для текущего уровня понимания сложности на ровном месте. Принципиальной разницы между этими ситуациями просто не вижу.
Никто не спорит, что распараллеливание хорошо. Я тоже делегирую задачи, но директору с формулировкой типа «вот ТЗ на вёрстку, я это буду делать N дней, хороший верстальщик сделает быстрее и тебе дешевле обойдётся» :)
Только поиск хорошего верстальщика займет 2^N дней… И не факт что найденный на самом деле окажется хорошим :)
Это не моя, как говорится, зона ответственности. Руководству предоставлена информация — пускай оно решает что и как. Решат, что коней нв переправе не меняю и придётся мне верстать с негативным отношением к процессу, да со влиянием того, что я свой уровень врстки оцениваю ниже среднего — мне сложно представить, чтобы кто-то сверстал хуже меня — например я так толком не разобрался в семантике многих новых тегов HTML/
«так что любая параллельность хороша, даже если она где-то по началу не супер-эффективна»
Очень опасное утверждение.
Любое рапараллеливание в проектном менджменте — это дополнительные риски.
Далеко не все задачи и далеко не все ресурсы параллелятся.
Очень опасное утверждение.
Любое рапараллеливание в проектном менджменте — это дополнительные риски.
Далеко не все задачи и далеко не все ресурсы параллелятся.
Если получится — это сделал не я, а подчиненные, если не получится — облажался я: никакой положительной мотивации в решении таких задач не вижу.
Какая знакомая ситуация. Мне тоже очень сложно получить правильную мотивацию при правильно делегировании задач, поэтому приходится насиловать себя и забирать часть работы (обычно самой сложной, либо принципиальной) себе, чтобы потом иметь хоть какие-то положительные эмоции от выполненной задачи.
И как исправить данную ситуацию неизвестно, думаю, только сменой рода деятельности.
В теории я решение знаю — нужно воспринимать достижение команды как своё: набрал хорошую команду, правильно распределил задачи, правильно организовал процесс, вовремя раздавал кнуты и пряники и т. п. Ведь негативные моменты так получается на себя брать: набрал плохую команду, неправильно раздал задачи, не контролировал и не мотивировал и т. д. — всё моя вина. Но, блин, только в теории, положительный результат в роли менеджера я эмоционально считаю как «на этот раз повезло, удачно звезды встали, карта легла». Как изменить своё отношение я не знаю, поэтому самоустраняюсь от менеджерских функций, выступая в роли технического эксперта и где-то в роли бизнес-аналитика для менеджера, выдавая, например, ТЗ для верстальщика менеджеру и проверяя его выполнение, но не вмешиваюсь в вопросы контроля и мотивации.
Хорошо что есть управленцы, и хорошо что не все хотят ими быть. Пусть те кто могут управлять, собирают талантов и притворяют достойные идеи в жизнь.
Меня терзают смутные сомнения, что эта неделя будет посвящена "[до-хрена] причин быть/не-быть/может-быть лидом"
Помойму, авторы обоих постов различают термины «менеджер» и «тимлид».
Одни управленцы в стране… Заводы стоят!!! Деталь тупо выточить некому, потому, что управленцы не знают как (а как можно управлять не понимая ссуть?), а остальные — юристы, программисты и гитаристы. Все. Это полный крах, дальше уже некуда.
Да, хоть бы и после грузчика. Или Вас это чем-то задевает?
А я не говорю, что сейчас работаю грузчиком. Но трудяга, да, это Вы это в точку. По ночам я сплю здоровым крепким сном, чего и Вам желаю конечно; и не пишу никакие эмуляторы приставок. Но думаю Вы не вправе не согласится, что кадры разные нужны, кадры разные важны. И что сейчас «управленцев», а по сути — офисных крыс плюющих в потолок и изредка, с пинка еще вышестоящих «управленцев» чего то делающих, поголовно больше, чем низкоквалифицированных подчиненных. Разве нет?
Ну я вышел из программиста, немного в теме, как бы :)
А заводы — модернизация должна быть в стратегических планах государства. Это вы к другим управленцам, которые эту стратегию пишут, обращайтесь :)
А заводы — модернизация должна быть в стратегических планах государства. Это вы к другим управленцам, которые эту стратегию пишут, обращайтесь :)
Фиговые управленцы раз не могут найти и(или) подготовить того, кто деталь выточит. Или на фиг та деталь никому не нужна, но управленцы и тут фиговые, раз думают о том, как е выточить.
P.S. Пишу как несостоявшийся менеджер машиностроительной промышленности. Одна из причин — понял, что придётся искать тех, кто может детали выточить.
P.S. Пишу как несостоявшийся менеджер машиностроительной промышленности. Одна из причин — понял, что придётся искать тех, кто может детали выточить.
Дизайнеры и блоггеры еще
Ещё один нюанс — качество специалиста проще проверить, чем качество управленца. Программиста можно попросить показать код, решить пару тестовых заданий — и его уровень будет ясен. А вот для управленцев таких тестов, к сожалению, нет.
Соответственно, есть масса «так-себе-управленцев», которые при этом претендуют на те же позиции, что и действительно профессиональные менеджеры, и отфильтровать их не так-то просто.
Я обычно руководствуюсь двумя критериями: «сколько человек было под началом» и «что делало руководимое подразделение». Потому что начальник отдела из 5 и из 30 человек — это две большие разницы. Но при этом отдел из 5 человек может быть, скажем, «отделом автоматизации» в маленьком банке и решать все его разнообразные потребности, а отдел из 30 — это может быть просто банда сисадминов, но в банке большом.
Но и это не всегда помогает. Кроме того, часто управленцев переманивают с должностей заместителя: дескать, карьерный рост, повышение — но заместитель может быть действительно правой рукой шефа, а может — чисто номинальной должностью, зато красиво раздувать щёки и рассказывать на собеседованиях о своей важности :)
Соответственно, есть масса «так-себе-управленцев», которые при этом претендуют на те же позиции, что и действительно профессиональные менеджеры, и отфильтровать их не так-то просто.
Я обычно руководствуюсь двумя критериями: «сколько человек было под началом» и «что делало руководимое подразделение». Потому что начальник отдела из 5 и из 30 человек — это две большие разницы. Но при этом отдел из 5 человек может быть, скажем, «отделом автоматизации» в маленьком банке и решать все его разнообразные потребности, а отдел из 30 — это может быть просто банда сисадминов, но в банке большом.
Но и это не всегда помогает. Кроме того, часто управленцев переманивают с должностей заместителя: дескать, карьерный рост, повышение — но заместитель может быть действительно правой рукой шефа, а может — чисто номинальной должностью, зато красиво раздувать щёки и рассказывать на собеседованиях о своей важности :)
согласен.
а еще их учить дольше и труднее, и тупо дороже получается.
а еще их учить дольше и труднее, и тупо дороже получается.
Если это соискатель на РП, например, предложите ему спланировать какой-нибудь выдуманный проект. За 5-7 минут в общих чертах концептуально.
Если это соискатель на тимлида, например, предложите ему за 5-7 минут накидать план организации процесса разработки на пустом месте.
Если это соискатель на тимлида, например, предложите ему за 5-7 минут накидать план организации процесса разработки на пустом месте.
Не мог бы ты привести пример «масштабируемости» из твоей практики? Какая у тебя была самая большая команда и на каком проекте?
Да в общем, не очень большой у меня опыт, не как у автора того поста.
Примеры
1. Автоматизация техподдержки. Суммарно 10 человек. Это в плане людей.
Условно, единый центр приема заявок со многих проектов (с десяток крупных ) + учет звонков (у нас разные группы клиентов, везде тысячами и десятками тысяч исчисляется письмо), плюс куча бизнес-процессов внутри компании (менеджеры, пишущие вопросы клиентам в техподдержку, для поддержки мониторинг, как их проблемы третьего уровня решают разработчики, и тд). Много всего.
2. В плане сложности — из недавнего. Перенос сложного проекта CRM с MySQL на PG и внедрение, плюс перенос части функционала из ранней версии CRM в текущую (карточка клиента). Это делала одна моя группа, там PM + программист. Трудное внедрение, так как 50 сейлзов, система должна работать постоянно. Плюс трудно технически, много кода перелопатили, а сроки (месяц) ограничены.
3. Вторая группа делала параллельно (вот что важно — одновременно у меня работает до пяти групп, результатов много) — создание движка так называемой умной рекламы, который должен откручивать нанескольких сайтах, один из которых 2 млн уников в месяц, рекламу с учетом индивидуальных предпочтений юзера, исходя из работы на этом сайте. Архитектор, два разработчика плюс один привлекался на ограниченные работы.
В целом возможность параллелить работу и давать людям возможность делать самостоятельно — это привлекает, это масштабируемо.
Примеры
1. Автоматизация техподдержки. Суммарно 10 человек. Это в плане людей.
Условно, единый центр приема заявок со многих проектов (с десяток крупных ) + учет звонков (у нас разные группы клиентов, везде тысячами и десятками тысяч исчисляется письмо), плюс куча бизнес-процессов внутри компании (менеджеры, пишущие вопросы клиентам в техподдержку, для поддержки мониторинг, как их проблемы третьего уровня решают разработчики, и тд). Много всего.
2. В плане сложности — из недавнего. Перенос сложного проекта CRM с MySQL на PG и внедрение, плюс перенос части функционала из ранней версии CRM в текущую (карточка клиента). Это делала одна моя группа, там PM + программист. Трудное внедрение, так как 50 сейлзов, система должна работать постоянно. Плюс трудно технически, много кода перелопатили, а сроки (месяц) ограничены.
3. Вторая группа делала параллельно (вот что важно — одновременно у меня работает до пяти групп, результатов много) — создание движка так называемой умной рекламы, который должен откручивать нанескольких сайтах, один из которых 2 млн уников в месяц, рекламу с учетом индивидуальных предпочтений юзера, исходя из работы на этом сайте. Архитектор, два разработчика плюс один привлекался на ограниченные работы.
В целом возможность параллелить работу и давать людям возможность делать самостоятельно — это привлекает, это масштабируемо.
Эх, максимализм.
В 21 год я то же был PM'ом группы из 7 человек (1 тестер, 2 BA, 1 суппорт, 3 разработчика), автоматизировал розницу одного банка из топ-20 на тот момент.
Просто вот это «Как управленец, я могу строить управленческие структуры, рабочие группы, и суммарный результат во много раз больше, чем если бы я сам кодил» ну никак не коррелирует с опытом руководства 10 сотрудниками, уж поверьте.
В 21 год я то же был PM'ом группы из 7 человек (1 тестер, 2 BA, 1 суппорт, 3 разработчика), автоматизировал розницу одного банка из топ-20 на тот момент.
Просто вот это «Как управленец, я могу строить управленческие структуры, рабочие группы, и суммарный результат во много раз больше, чем если бы я сам кодил» ну никак не коррелирует с опытом руководства 10 сотрудниками, уж поверьте.
Мне 25 :) Макс. опыт 30 человек руководства. Это чуть больше, чем управление проектами в рамках одной группы, поверьте.
Просто вы спросили в одной группе — да, всего лишь 10, не 100 и 1000, как у топикстартера.
Ничто не мешает мне сейчас управлять пятью группами, когда год назад и с двумя было тяжеловато. Иерархии именно для этого придумали (взяли из природы, точнее).
Где тут максимализм? В формулировке разве что.
Просто вы спросили в одной группе — да, всего лишь 10, не 100 и 1000, как у топикстартера.
Ничто не мешает мне сейчас управлять пятью группами, когда год назад и с двумя было тяжеловато. Иерархии именно для этого придумали (взяли из природы, точнее).
Где тут максимализм? В формулировке разве что.
Я управляю проектами два года, и только начинающий project manager, по сути дела. В отделе 15 человек, несколько проектных групп. Менеджер среднего звена — управляю теми, кто управляет программистами. При этом напрямую также веду программистов и ряд проектов. До этого три года был ведущим web-программистом, до этого стартапы, своя студия, фриланс и тд.А почему сменили «свою студию» на корпоративного менеджера проектов? Ведь в своей студии управлять должно быть интереснее и, возможно, выгоднее?
в то время я был очень молодой и неопытный. и работал оперативным управленцем, а также занимался продажами и тд.
только зарождался Веблансер, был 2007 год )
это вовсе не так круто, как сейчас управлять в стартапе, на готовых деньгах инвестора и привлекая лучших проггеров на дикие зарплаты (из денег инвесторов). и джумлосайты делать неинтересно стало, и просто делать мелочи непрофильные (быть аутсорс кодинг конторой).
короче, много геммороя и мало интересного. деньги мало решают, их не было много.
вот если бы в будущем, прокачав навыки продаж, маркетинга, финансового менеджмента, юридические, бухучет и тд (для контроля спецов, которым делегируешь), можно и подумать о своем деле. но если его можно, допустим, открыть в рамках текущей конторы, не лучше ли расти по текущему пути?
вообщем классический PM — это как раз мини-бизнес в рамках компании. есть бюджет. проект, ресурсы, риски. дали пистолет и крутись, как в анекдоте :) только инфраструктура вся — от продаж до бухучета и тд — готовая, а ты не создаешь ее с нуля, как в своем деле на 100%.
только зарождался Веблансер, был 2007 год )
это вовсе не так круто, как сейчас управлять в стартапе, на готовых деньгах инвестора и привлекая лучших проггеров на дикие зарплаты (из денег инвесторов). и джумлосайты делать неинтересно стало, и просто делать мелочи непрофильные (быть аутсорс кодинг конторой).
короче, много геммороя и мало интересного. деньги мало решают, их не было много.
вот если бы в будущем, прокачав навыки продаж, маркетинга, финансового менеджмента, юридические, бухучет и тд (для контроля спецов, которым делегируешь), можно и подумать о своем деле. но если его можно, допустим, открыть в рамках текущей конторы, не лучше ли расти по текущему пути?
вообщем классический PM — это как раз мини-бизнес в рамках компании. есть бюджет. проект, ресурсы, риски. дали пистолет и крутись, как в анекдоте :) только инфраструктура вся — от продаж до бухучета и тд — готовая, а ты не создаешь ее с нуля, как в своем деле на 100%.
то есть короткий ответ
1. там было неинтересно
2. не было выбора проектов, трудно было с ресурсами (кто сам искал проггеров или даже дизайнеров на фрилансе в веб-студиях, знает)
3. денег было не так много
4. я просто не тянул это профессионально.
1. там было неинтересно
2. не было выбора проектов, трудно было с ресурсами (кто сам искал проггеров или даже дизайнеров на фрилансе в веб-студиях, знает)
3. денег было не так много
4. я просто не тянул это профессионально.
«У нас проекты — как стартапы, в разных сферах.»
«Любой проект можно развивать бесконечно.»
«A project is a temporary endeavor undertaken to create a unique product, service, or result» © PMBOK Guide 4th Ed
«Любой проект можно развивать бесконечно.»
«A project is a temporary endeavor undertaken to create a unique product, service, or result» © PMBOK Guide 4th Ed
Есть такое дело.
Я пока только учусь, пмбок проглядывал и пока ясно одно, мы пока не так круты, чтобы юзать эту мощь.
Я перефразирую. Речь о состояниях. Мы выделяем разные фазы развития проекта. Среди этих фаз есть самодостаточность раздела. Это когда вроде работает и показатели в норме, но можно улучшить.
Давайте за пример Хабр. Раздел профиль пользователя. Я захожу в мои посты, и сразу понимаю, что не хватает фильтра. По блогу, поиск по ключевому слову. Возможно год и месяц статьи, искать их было бы муторно без гуглопоиска по хабру. И еще миллион улучшений вы мне назовете сами, так как вы и я в шкуре пользователя проекта.
НО!
1. Основные задачи раздел решает, то есть стадия самодостаточности есть
2. Новый функционал типа фильтров может быть экономически не оправдан и не совпадать со стратегией развития
3. Всегда, делая одно, мы не делаем другое. Вот понять, что в каком порядке делать, от чего отказаться сейчас а от чего нет — это тоже работа проблеете и очень мало кто умеет это делать. Я только учусь, еще не умею
Я пока только учусь, пмбок проглядывал и пока ясно одно, мы пока не так круты, чтобы юзать эту мощь.
Я перефразирую. Речь о состояниях. Мы выделяем разные фазы развития проекта. Среди этих фаз есть самодостаточность раздела. Это когда вроде работает и показатели в норме, но можно улучшить.
Давайте за пример Хабр. Раздел профиль пользователя. Я захожу в мои посты, и сразу понимаю, что не хватает фильтра. По блогу, поиск по ключевому слову. Возможно год и месяц статьи, искать их было бы муторно без гуглопоиска по хабру. И еще миллион улучшений вы мне назовете сами, так как вы и я в шкуре пользователя проекта.
НО!
1. Основные задачи раздел решает, то есть стадия самодостаточности есть
2. Новый функционал типа фильтров может быть экономически не оправдан и не совпадать со стратегией развития
3. Всегда, делая одно, мы не делаем другое. Вот понять, что в каком порядке делать, от чего отказаться сейчас а от чего нет — это тоже работа проблеете и очень мало кто умеет это делать. Я только учусь, еще не умею
Это была просто придирка.
Судя по описанию, вы безусловно занимаетесь управлением и являетесь членом Project Management Team. Но вот Project Manager ли вы?..
Очень часто возникает путаница. Технический руководитель — это не руководитель проекта. Как и TechLead, как и TeamLead.
Зачастую, определения и круг обязанностей в разных компаниях настолько отличаются, что невольно задаёшь себе вопрос: «А я-то тогда кто?»
Во многих государтвенных (или бывших) организациях это вообще невозможно понять. И должности называются настолько длинно и сложно, что сотрудники первый год сами подглядывают названия в подписях к своим же сообщениям в Outlook.
Благо, с сентября вступили в силу ГОСТ Р 54869-2011, ГОСТ Р 54870-2011, ГОСТ Р 54871-2011. Надеюсь, теперь всё устаканится.
По иронии судьбы, курировал разработку стандартов Евгений Петросян. Нет, слава Богу, не тот…
Судя по описанию, вы безусловно занимаетесь управлением и являетесь членом Project Management Team. Но вот Project Manager ли вы?..
Очень часто возникает путаница. Технический руководитель — это не руководитель проекта. Как и TechLead, как и TeamLead.
Зачастую, определения и круг обязанностей в разных компаниях настолько отличаются, что невольно задаёшь себе вопрос: «А я-то тогда кто?»
Во многих государтвенных (или бывших) организациях это вообще невозможно понять. И должности называются настолько длинно и сложно, что сотрудники первый год сами подглядывают названия в подписях к своим же сообщениям в Outlook.
Благо, с сентября вступили в силу ГОСТ Р 54869-2011, ГОСТ Р 54870-2011, ГОСТ Р 54871-2011. Надеюсь, теперь всё устаканится.
По иронии судьбы, курировал разработку стандартов Евгений Петросян. Нет, слава Богу, не тот…
Должность у меня вообще руководитель отдела. И много, связанного с этим, тоже решаю. Административная нагрузка в минус, зато контроль над ресурсами и людьми в плюс. Много плюшек за и против.
Но специальность и основной вид деятельности, конечно, PM. По мере роста моего профессионализма он все ближе в плане полномочий и возможностей к классическому варианту.
Но специальность и основной вид деятельности, конечно, PM. По мере роста моего профессионализма он все ближе в плане полномочий и возможностей к классическому варианту.
А как вы для себя определяете менеджера проектов? Кто это?
В таких случаях я обращаюсь к стандартам.
Например, PMI PMBOK.
Если же структура компании и её корпоративные культура и нормы совсем уж уникальные и ни на что не похожие, тогда надо руководствоваться именно этими нормами.
Но, мне кажется, лучше велосипедов не выдумывать и использовать то, что есть. Хотя бы для того, чтобы разговаривать на одном языке с остальными.
Например, PMI PMBOK.
Если же структура компании и её корпоративные культура и нормы совсем уж уникальные и ни на что не похожие, тогда надо руководствоваться именно этими нормами.
Но, мне кажется, лучше велосипедов не выдумывать и использовать то, что есть. Хотя бы для того, чтобы разговаривать на одном языке с остальными.
Да, язык важен, и общение с коллегами. Важны стандарты и чужой опыт.
Но у меня задачи пока проще. Сначала добиваться результата в заданной системе ограничений. Недавно добавилась задача определять, что есть результат, и самому строить системы, в которых команды результативно работают.
Но у меня задачи пока проще. Сначала добиваться результата в заданной системе ограничений. Недавно добавилась задача определять, что есть результат, и самому строить системы, в которых команды результативно работают.
Та же пмбок при изучении показала, что пока для нас это как из пушки по воробьям. Или мы не умеем его готовить :)
Это заблуждение.
Вы, вероятно, просто поверхностно ознакомились с руководством.
Так что скорее просто не умеете его готовить.
Сходите на курсы, мастер-классы, посмотрите, как это работает не только в больших, но и в самых маленьких компаниях и проектах.
Вы, вероятно, просто поверхностно ознакомились с руководством.
Так что скорее просто не умеете его готовить.
Сходите на курсы, мастер-классы, посмотрите, как это работает не только в больших, но и в самых маленьких компаниях и проектах.
Из проб других методик и подходов, более простых и айтишных, типа скрама, появилось впечатление, что это тупо товар и продавцы серебряной пули
Более того, у меня один бывший сотрудник получил сертификат именно пмбока, но на работе его сказалось слабо. Плюс фишка, что сертификат устаревает и его надо ехать пересдавать за бабло снова тоже насторожило.
Польза была у другой знакомой. Уехав зарубеж, сертификаты сняли ряд вопросов на собеседовании и полвинули резюме в списке выше. Все.
А так я считаю, это просто набор стандартов и ничего более. Как вы верно сказали, голова нужна. А еще тупо реальные навыки, такие как контроль над задачами или дожимание до результата, или конкретный опыт расчета сроков и стоимости разработки и доведения проекта до результата в соответствии с тем, что ты там насчитал.
Вот этому что-то пока никто не учит.
Более того, у меня один бывший сотрудник получил сертификат именно пмбока, но на работе его сказалось слабо. Плюс фишка, что сертификат устаревает и его надо ехать пересдавать за бабло снова тоже насторожило.
Польза была у другой знакомой. Уехав зарубеж, сертификаты сняли ряд вопросов на собеседовании и полвинули резюме в списке выше. Все.
А так я считаю, это просто набор стандартов и ничего более. Как вы верно сказали, голова нужна. А еще тупо реальные навыки, такие как контроль над задачами или дожимание до результата, или конкретный опыт расчета сроков и стоимости разработки и доведения проекта до результата в соответствии с тем, что ты там насчитал.
Вот этому что-то пока никто не учит.
Простите за жесткость. Где-нибудь в Газпроме, где у знакомого моего проджект менеджеры это крутые бумажко писатели, нужны конечно стандарты, ГОСТы, законы.
У меня же айти, автоматизация бизнеса, задачи именно такие, четкие.
У меня же айти, автоматизация бизнеса, задачи именно такие, четкие.
Про пмбок от опытных товарищей слышал, что для бюджета от миллиона долларов это рулез и ничего лучше не надо.
У нас в 5-30 раз меньше бюджеты на проекты, и плюс сложные условия, что нам ближе всего методология XP.
У нас в 5-30 раз меньше бюджеты на проекты, и плюс сложные условия, что нам ближе всего методология XP.
XP — это методология разработки.
Но не управления проектами.
Я не настаиваю на PMBOK, я наставиваю на осмыслении и управлении. Проектами, раз уж мы о них стали говорить. А уж к чему вы в итоге придёте — это вам решать и время покажет.
«Ничего лучше не надо» — это неправильный подход. Improvement должен быть всегда.
Но не управления проектами.
Я не настаиваю на PMBOK, я наставиваю на осмыслении и управлении. Проектами, раз уж мы о них стали говорить. А уж к чему вы в итоге придёте — это вам решать и время покажет.
«Ничего лучше не надо» — это неправильный подход. Improvement должен быть всегда.
Поэтому я и написал выше, что самое главное — это светлая голова и здравый смысл.
Всяческие стандарты и методологии — это не панацея, не догма и уж точно не серебрянная пуля.
Собственно, в некоторых стандартах это чёрным по белому пишут.
Всяческие стандарты и методологии — это не панацея, не догма и уж точно не серебрянная пуля.
Собственно, в некоторых стандартах это чёрным по белому пишут.
Работать без методологии можно, просто опираясь на здравый смысл (а в управлении на 99% именно он, а не специфические знания). Проблема заключается в том, что каждый уверен в том, что именно у него со здравым смыслом все в порядке. И если удалось несколько лет в индустрии продержаться, то и «опыт» появляется. И вот такой чувак, со «своим видением» и «опытом» дров способен наломать немало. Поэтому общепринятый стандарт, методология, позволяет убедиться, что с человеком хотя бы можно говорить на одном языке. Что ему не нужно объяснять, кто такие стейкхолдеры и почему важно утверждать с ними требования к проекту. Зачем нам расписывать risks mitigation plan заранее и почему нельзя закрыть проект просто после того как он сдан заказчику.
Да, можно иметь РМР-сертификат, вызубрить PMBOK на память и быть плохим менеджером проектов. Точно так же можно вызубрить правила дорожного движения, и быть плохим водителем. Но без знания правил лучше все же на дорогу не выезжать в принципе.
Да, можно иметь РМР-сертификат, вызубрить PMBOK на память и быть плохим менеджером проектов. Точно так же можно вызубрить правила дорожного движения, и быть плохим водителем. Но без знания правил лучше все же на дорогу не выезжать в принципе.
А какой у вас опыт управления проектами?
У меня тоже «всё сложно».
Занимался управлением проектами я более 4 лет.
Но твёрдо PM я 2 года.
Занимался управлением проектами я более 4 лет.
Но твёрдо PM я 2 года.
Светлая голова и зравый смысл — главное. Разуммется, но имхо рекомендации разработаны чтоб 1. Импрувмент должен быть всегда. 2 для тех у кого голова не такая светлая и смысл не такой здравый (разрабатываются фреймворки именно теми у кого со светлостью и здравым смыслом все ок, чтобы управлять ресурсами).
Вот только для рф характерен тотальный непрофессионализм. вообще начну с того что бОльшая часть людей не знает что такое методология, а бОльшая часть трудящихся менеджеров в нашей стране в соотвествующей сфере особенно крупных компаний очень далеко стоят от методологий в управлении проектов.
Классический пример — менеджер отвечающий за интернет проект со стороны клиента (раработка интернет магазина линейки проудктов) с трудом отвечает что такое браузер. и поэтому токого рода хай левел в управлении проектами в нашей стране просто модель. Несмотря на то что пмбоке в общем рассматривается ситуация с отрицательной полезностью стейкхолдера итп. сложно представляю как можно объяснить управление рисками субъекту, который сам является самым большим риском проекта (что нужно сделать чтобы запуститься к дедлайну — выпей йаду и не мешай).
Или вот еще — задачу по разработке дизайна ставит один человек, а результат работы принимает другой, не соблюдая последовательность в разработке.
Разумеется понятно как это разруливать, но ведь хочется работать грамотно и эффективно, по плану проекта.
Много всего хочется написать да как то грустно.
Вот только для рф характерен тотальный непрофессионализм. вообще начну с того что бОльшая часть людей не знает что такое методология, а бОльшая часть трудящихся менеджеров в нашей стране в соотвествующей сфере особенно крупных компаний очень далеко стоят от методологий в управлении проектов.
Классический пример — менеджер отвечающий за интернет проект со стороны клиента (раработка интернет магазина линейки проудктов) с трудом отвечает что такое браузер. и поэтому токого рода хай левел в управлении проектами в нашей стране просто модель. Несмотря на то что пмбоке в общем рассматривается ситуация с отрицательной полезностью стейкхолдера итп. сложно представляю как можно объяснить управление рисками субъекту, который сам является самым большим риском проекта (что нужно сделать чтобы запуститься к дедлайну — выпей йаду и не мешай).
Или вот еще — задачу по разработке дизайна ставит один человек, а результат работы принимает другой, не соблюдая последовательность в разработке.
Разумеется понятно как это разруливать, но ведь хочется работать грамотно и эффективно, по плану проекта.
Много всего хочется написать да как то грустно.
Есть такое дело.
Я пока только учусь, пмбок проглядывал и пока ясно одно, мы пока не так круты, чтобы юзать эту мощь.
Я перефразирую. Речь о состояниях. Мы выделяем разные фазы развития проекта. Среди этих фаз есть самодостаточность раздела. Это когда вроде работает и показатели в норме, но можно улучшить.
Давайте за пример Хабр. Раздел профиль пользователя. Я захожу в мои посты, и сразу понимаю, что не хватает фильтра. По блогу, поиск по ключевому слову. Возможно год и месяц статьи, искать их было бы муторно без гуглопоиска по хабру. И еще миллион улучшений вы мне назовете сами, так как вы и я в шкуре пользователя проекта. А работа проджекта сродни работе актера — вы должны перевоплотиться в своего клиента, в своего пользователя, работать с живыми клиентами, иначе не поймете, как нужно сделать продукт качественным и удобным, решающим именно те задачи, которые нужны вашим клиентам.
НО!
1. Основные задачи раздел решает, то есть стадия самодостаточности есть
2. Новый функционал типа фильтров может быть экономически не оправдан и не совпадать со стратегией развития
3. Всегда, делая одно, мы не делаем другое. Вот понять, что в каком порядке делать, от чего отказаться сейчас, а от чего нет — это тоже работа проджекта и очень мало кто умеет это делать. Я только учусь, еще не умею
Я пока только учусь, пмбок проглядывал и пока ясно одно, мы пока не так круты, чтобы юзать эту мощь.
Я перефразирую. Речь о состояниях. Мы выделяем разные фазы развития проекта. Среди этих фаз есть самодостаточность раздела. Это когда вроде работает и показатели в норме, но можно улучшить.
Давайте за пример Хабр. Раздел профиль пользователя. Я захожу в мои посты, и сразу понимаю, что не хватает фильтра. По блогу, поиск по ключевому слову. Возможно год и месяц статьи, искать их было бы муторно без гуглопоиска по хабру. И еще миллион улучшений вы мне назовете сами, так как вы и я в шкуре пользователя проекта. А работа проджекта сродни работе актера — вы должны перевоплотиться в своего клиента, в своего пользователя, работать с живыми клиентами, иначе не поймете, как нужно сделать продукт качественным и удобным, решающим именно те задачи, которые нужны вашим клиентам.
НО!
1. Основные задачи раздел решает, то есть стадия самодостаточности есть
2. Новый функционал типа фильтров может быть экономически не оправдан и не совпадать со стратегией развития
3. Всегда, делая одно, мы не делаем другое. Вот понять, что в каком порядке делать, от чего отказаться сейчас, а от чего нет — это тоже работа проджекта и очень мало кто умеет это делать. Я только учусь, еще не умею
Прошу прощения за дубль
Желаю жить как Миша Галустян — иметь душ триста крепостных крестьян…
>Я прочитал пост «13 причин не быть управленцем» и хочу написать ответ.
Тот пост: «Не становитесь управленцем! Это сложно, а потому плохо!»
Этот пост: «Станьте управленцем! Это сложно, а потому интересно!»
Может всё-таки проблемы не в должности, а в психотипе?
Тот пост: «Не становитесь управленцем! Это сложно, а потому плохо!»
Этот пост: «Станьте управленцем! Это сложно, а потому интересно!»
Может всё-таки проблемы не в должности, а в психотипе?
Вы внимательно читали?
Написано: Поэтому универсальных советов нет, каждому нужно искать свое дело.
Написано: Поэтому универсальных советов нет, каждому нужно искать свое дело.
Дело не в сложности, дело в том какая это сложность. Управленческая сложность неуправляемая, непредсказуемая, несистематизируемая, неформализуемая. Нельзя поставить эксперимент и посмотреть, что будет, а потом откатиться как будто его и не было — начинать придётся не с нуля, а из минусов вылазить как чисто финансовых, так и репутационных, психологических и т. п. опять же неквалифицируемых, неформализуемых и т. д. Всё время приходится «работать на продакшене», а не на «уютном дев-сервере».
А давайте все станем управленцами? И будем друг другом управлять! Вот круто будет! :)
Вот в таких статьях всегда раздражает то, что автор как будто бы забвает, что управленцы не нужны. Без управленцев программисты запросто создают отличные продукты, а вот управленцы без программитсов — ничего не создают, кроме отчётов.
И много можно найти успешных проектов, построенных без управленцев (продукты, которые можно выпустить силами 1-3 человек в расчет брать не будем)?
Steam?
Пруф?
раз: 35 млн пользователей и его делает Valve ru.wikipedia.org/wiki/Steam
два: в Valve нет менеджеров habrahabr.ru/post/142645/
Значит Стим — крупный продукт, сделаный без менеджеров
два: в Valve нет менеджеров habrahabr.ru/post/142645/
Значит Стим — крупный продукт, сделаный без менеджеров
В статье упоминается некое «руководство». Также ничего не сказано что в проектах нет руководителей. Да, структура компании непостоянная, но нигде не сказано, что нет управляющих ролей.
Мне почему-то кажется, что если копнуть глубже, то окажется, что всё «отсутствие руководства» заключается только в свободном перемещении сотрудников между проектами
я согласен.
какой % таких программистов, и какой тех, кто делает сам 99% и бросает?
какой % таких программистов, и какой тех, кто делает сам 99% и бросает?
Только в случае если один из программистов берёт на себя роль управленца: «мы посовещались и я решил». Даже если брать опенсорс проект на гитхабе, то обычно кто-то один (или небольшая группа) решает какие пулл реквесты принимать, а какие — нет. В крайнем случае вырабатывает механизм коллективного принятия решений («пулл реквесты принимаем по результатам голосования за неделю») и разруливает спорные моменты.
Вот типичный управленец — он мотивирует. Пред. статья должна быть в топе на demorivators.bla
Спасибо тебе добрый фей!
Спасибо тебе добрый фей!
Перечитал.
Пункт 1. А как насчёт системы на 35 миллионов пользователей, построенной и отлично работающей без менеджера?
Пункт 2 вообще пушка — «я не хочу учиться, хочу один раз и чтоб потом бабло грести». Просто ода лени.
Пункты 3, 4 и 5 — про интенсивность, бесконечность и ответственность в той же степени подходят и программистам. С той разницей, что менеджеры об этом говорят, а программисты делают. Собственно программисты и создают эту самую «бесконечность развития», и несут ответственность за себя и за менеджера. Ведь если программист ошибается — переделывает он. А когда ошибается менеджер — переделывает снова программист.
Пункт 1. А как насчёт системы на 35 миллионов пользователей, построенной и отлично работающей без менеджера?
Пункт 2 вообще пушка — «я не хочу учиться, хочу один раз и чтоб потом бабло грести». Просто ода лени.
Пункты 3, 4 и 5 — про интенсивность, бесконечность и ответственность в той же степени подходят и программистам. С той разницей, что менеджеры об этом говорят, а программисты делают. Собственно программисты и создают эту самую «бесконечность развития», и несут ответственность за себя и за менеджера. Ведь если программист ошибается — переделывает он. А когда ошибается менеджер — переделывает снова программист.
1. я только за
когда была своя студия, поначалу был и жрец, и жнец, и на дуде игрец. и продавец сам себе, и бухгалтер, и PM, и верстальщик, и техподдержка.
если программист тянет другие роли, в том числе делает управленческую работу — пожалуйста.
у меня друг есть, лидер по разработке в Livestreet, Всех рвет. адепт качества, клиенты его любят. Прекрасно сам и продает, и в маркетинге шарит, и продукты делает высочайшего качества кода.
2. ода лени, и ода разумности.
вот в Dolphin Olympics наибольшие очки набираются, только если каждый следующий прыжок основан на предыдущем. упал — все, мало очков будет.
так и тут — часто, обучаясь с нуля, ты перегружаешь мозги. хорошо это — да, с одной стороны, растет кругозор. умел на ООП писать, теперь на функционале, знал ассемблер, а теперь вот на сях драйвер накатал.
с другой стороны, сфокусированный спец за это же время прокачает скиллы выше.
здравый смысл онли :)
3. согласен со всем, кроме ответственности
если менеджер проекта (продукта) придумал неверный раздел, неверный маркетинг и так далее, то беда ему, а не программеру. программер сделал — и молодец, все четко, получил ЗП. а вот продукт не взлетел с новой фишкой, бюджет в минусах и у PMа бонус потерян. так что тут зависит от ситуации :)
когда была своя студия, поначалу был и жрец, и жнец, и на дуде игрец. и продавец сам себе, и бухгалтер, и PM, и верстальщик, и техподдержка.
если программист тянет другие роли, в том числе делает управленческую работу — пожалуйста.
у меня друг есть, лидер по разработке в Livestreet, Всех рвет. адепт качества, клиенты его любят. Прекрасно сам и продает, и в маркетинге шарит, и продукты делает высочайшего качества кода.
2. ода лени, и ода разумности.
вот в Dolphin Olympics наибольшие очки набираются, только если каждый следующий прыжок основан на предыдущем. упал — все, мало очков будет.
так и тут — часто, обучаясь с нуля, ты перегружаешь мозги. хорошо это — да, с одной стороны, растет кругозор. умел на ООП писать, теперь на функционале, знал ассемблер, а теперь вот на сях драйвер накатал.
с другой стороны, сфокусированный спец за это же время прокачает скиллы выше.
здравый смысл онли :)
3. согласен со всем, кроме ответственности
если менеджер проекта (продукта) придумал неверный раздел, неверный маркетинг и так далее, то беда ему, а не программеру. программер сделал — и молодец, все четко, получил ЗП. а вот продукт не взлетел с новой фишкой, бюджет в минусах и у PMа бонус потерян. так что тут зависит от ситуации :)
The pace of technology is slower than you think.
Есть мнение, что вырасти с программиста до руководителя отдела/группой и т.п. сложно на одном месте. Что вы думаете об этом?
It depends.
Сложно.
Обычно тебя стараются максимально использовать как программиста, хотя ты уже прямым текстом руководству заявляешь, что больше заниматься этим не хочешь. В результате доходит до того, что просто уходишь в другое место и там начинаешь уже с другой должности.
Более того! Кадровые агентства, видя в резюме твоё программистское прошлое, названивают тебе и пытаются соблазнить именно на программиста в первую очередь.
Очень часто такое бывает.
Обычно тебя стараются максимально использовать как программиста, хотя ты уже прямым текстом руководству заявляешь, что больше заниматься этим не хочешь. В результате доходит до того, что просто уходишь в другое место и там начинаешь уже с другой должности.
Более того! Кадровые агентства, видя в резюме твоё программистское прошлое, названивают тебе и пытаются соблазнить именно на программиста в первую очередь.
Очень часто такое бывает.
Согласен, причем кадровые агентства предлагают работу именно на программиста в таких случаях или из-за не внимательности или «а вдруг прокатит», мое мнение.
Бывает и наоборот. Если ты самый квалифицированный программист или просто занимаешься ключевыми моментами типа архитектуры или API, да ещё постоянно выступаешь с инициативами внедрения тех или иных методологий и (или) инструментов разработки, критикой существующих методов управления и т. п., то сначала тебя назначают разово ответственным за внедрение твоего предложения или за какой-то модуль системы, требующий координации нескольких сотрудников, потом ещё раз, ещё, потом замечаешь, что уже почти не кодишь, а только организовываешь, координируешь, да контролируешь, начинаешь говорить начальству прямым текстом, что хочешь код писать, а не выяснять почему Вася третий день простую страничку сверстать не может, а тебя говорят «привыкай, через месяц официально тебя начальником сделаем, выделим отдел разработки». В результате доходит до того, что уходишь в другое место и там начинаешь «с нуля».
Любой проект можно развивать бесконечно. Генерить идеи, делать их, доставлять пользователям, выкатывать новый функционал. Это творчество в чистом виде.
Вот так вот и получается часто из хорошего проекта неподдерживаемый пластилиновый ком, на который менеджеры хотят лепить всё новые и новые фичи, «бесконечно его развивая», даже если архитектура изначально вообще не была на них рассчитана, и не давая при этом времени на рефакторинг.
Архитектура всегда устаревает. Вот вчера погода была дождливой, вы оделись и взяли зонт. Сегодня +35 и вы в шортах. Да, есть цикл зима-весна-лето-осень, но он глобален, а все дело в мелочах.
Так и в приложении — рынок растет, клиенты хотят новых вещей, а старые приходится убирать, и проект должен эволюционировать. Эволюционное проектирование — см. Мартина на эту тему «Проектирования больше нет?»
www.maxkir.com/sd/designDead_RUS.html
А если получается говно — ну см. выше про дилетантов. Правило 5% профессионалов никто не отменял.
Так и в приложении — рынок растет, клиенты хотят новых вещей, а старые приходится убирать, и проект должен эволюционировать. Эволюционное проектирование — см. Мартина на эту тему «Проектирования больше нет?»
www.maxkir.com/sd/designDead_RUS.html
А если получается говно — ну см. выше про дилетантов. Правило 5% профессионалов никто не отменял.
Хороший менеджер даёт, даже если он такого слова не знает. Он верит на слово (и консультируется на стороне :) наиболее ответственным сотрудникам, болеющим за продукт и фирму, что технический долг скоро перевалит за критическую отметку.
Это значит, если мы хотим создать автоматизацию договорного отдела, или технической поддержки для обслуживания 10,000 клиентов, то нужна работа команды. В одиночку сделать такое трудно.
TЗ, пожалуйста. Очень сомневаюсь, что автоматизацию договорного отдела сделать в одиночку трудно. 10 000 клиентов — это может быть много, но обрабатываться может «одним, но очень гордым запросом» ))
я и так слишком детально, пожалуй, пишу. остальное, как говорится, коммерческое тайна :))))
но изначально первую версию системы сделал я, прототипчик живой :). а вот до ума ее довели и включили в цепочку других проектов, включая CRM, многие хорошие программисты.
но изначально первую версию системы сделал я, прототипчик живой :). а вот до ума ее довели и включили в цепочку других проектов, включая CRM, многие хорошие программисты.
Трудно. Можно быть хорошим программистом, но никаким бизнес-аналитиком или юзабилистом (см. «линукс пишут программисты для программистов»).
Или другими словами, программисты оживляют проект, делают то, что остальные нарисовали, спроектировали и так далее.
!!! Гнать проектировщиком-рисователей паганой метлой из индустрии!!! Когда уже люди мозгами дойдут, что не бывает хорошего кода по рисункам. Что не бывает хорошего программиста без того, чтобы он сам разбивал задачу и проектировал. Что говнокод рождается тогда, когда программисту раскладывают как что-то делать, а что, он не понимает. Что все рисунки убогие в сравнении с языком программирования. Что рисунки не дают понимания, какой говнокод из них получится. Что только код-говнокод показывает сам собой, какие в нем проблемы. Что проектируют не раз и навсегда, а рефакторят. Что программист — это человек умеющий читать и писать код, а рисунки — это удел САНТЕХНИКОВ в нашей индустрии. Сантехники захватили корыто и пытаются управлять программистами, но код не понимают и любят рисовать трубы и сливные бачки. Что тот, кто не понимает эволюционного проектирования (по коду), не умеет проектировать и наперед ВООБЩЕ. Что что что что. Таких утверждений можно на книгу набрать
Не соглашусь. Если картинки рисуют дауны — то это то да.
В ответку: вам не страшно будет ходить по мосту, который построят джамшуты без проектирования, учёта миллиарда факторов и т.д.? Мне весьма страшно.
Делать что-то не думая — страшное зло. В догонку вашей справедливой ненависти к проектировщикам-даунам — двойное зло. Гнать надо не всех, а даунов. Учимся не обощать.
В ответку: вам не страшно будет ходить по мосту, который построят джамшуты без проектирования, учёта миллиарда факторов и т.д.? Мне весьма страшно.
Делать что-то не думая — страшное зло. В догонку вашей справедливой ненависти к проектировщикам-даунам — двойное зло. Гнать надо не всех, а даунов. Учимся не обощать.
Если вы считаете, что программист — это джамшут и ему надо дать строгие указания — то так и будет. Будет очень серьезное превышение бюджета, даже если набрать дешевых джамшутов. Будет очень серьезное превышение сроков проекта. Будет много багов. Но, может быть, когда-то сможете завершить проект.
Личный совет, может не вам, а сомневающимся, курить TDD. Понять, что это такое — эволюционное проектирование. Почему так и каким образом архитектура рождается из кода.
Думать наперед, это равносильно «воображать» — удел гуманитариев. Приводящий к необоснованным решениям. Странно, что иногда даже при этом «водопадном» процессе мосты не падают.
Думать не надо, надо знать. Есть правила, набор методик, способы оценки. Проектирование в картинках — это чистое художество, упражнения в вымыслах. Сам процесс уже даунский, кто бы его не проводил. Рисунки делаются, но делаются в конце, когда уже что-то получилось и не изменится. Рисунки делаются иногда на совещаниях в начале, но на доске, фломастером или на бумажках от руки — но очень высокоуровневые и просто для обсуждения. Такие рисунки потом скорее всего выбрасываются. Главное проектирование происходит в процессе кодирования.
Личный совет, может не вам, а сомневающимся, курить TDD. Понять, что это такое — эволюционное проектирование. Почему так и каким образом архитектура рождается из кода.
Думать наперед, это равносильно «воображать» — удел гуманитариев. Приводящий к необоснованным решениям. Странно, что иногда даже при этом «водопадном» процессе мосты не падают.
Думать не надо, надо знать. Есть правила, набор методик, способы оценки. Проектирование в картинках — это чистое художество, упражнения в вымыслах. Сам процесс уже даунский, кто бы его не проводил. Рисунки делаются, но делаются в конце, когда уже что-то получилось и не изменится. Рисунки делаются иногда на совещаниях в начале, но на доске, фломастером или на бумажках от руки — но очень высокоуровневые и просто для обсуждения. Такие рисунки потом скорее всего выбрасываются. Главное проектирование происходит в процессе кодирования.
Дык! Когда у нас система проста и есть девелоперы, которые в себе частично проектировщиков объединяют, то завсегда.
Я не верю, что что-то реально большое и сложное можно сделать, условно говоря, силами одного человека.
Любые рисунки, чертежи, доки и т.д. — это банальное разбиение задачи, её распил (ВНИМАНИЕ! слово здесь не в том значении, как все подумали!). Если это разбиение сделано говнисто, то в итоге будет отменное удобрение.
Но отрицать вот так вот сходу и именовать проектирование даунством я… Я просто глаза-лоб.
ps: Btw, думать наперёд — это то, что нас из обизяны сделало.
pps: А давайте конкретику — что именно и когда в каком контексте вас крайне огорчило, что вы плюётесь на картинки? При вас сказать UML — это высшей степени грех? :) Конкретику в студию плиз и желательно чтобы это был опыт не одной конторы, где даунски проектирование поставлено, а нескольких.
ppps: А может мы вообще не так что-то понимаем? Опять же конкретика спасёт отца РД.
Я не верю, что что-то реально большое и сложное можно сделать, условно говоря, силами одного человека.
Любые рисунки, чертежи, доки и т.д. — это банальное разбиение задачи, её распил (ВНИМАНИЕ! слово здесь не в том значении, как все подумали!). Если это разбиение сделано говнисто, то в итоге будет отменное удобрение.
Но отрицать вот так вот сходу и именовать проектирование даунством я… Я просто глаза-лоб.
ps: Btw, думать наперёд — это то, что нас из обизяны сделало.
pps: А давайте конкретику — что именно и когда в каком контексте вас крайне огорчило, что вы плюётесь на картинки? При вас сказать UML — это высшей степени грех? :) Конкретику в студию плиз и желательно чтобы это был опыт не одной конторы, где даунски проектирование поставлено, а нескольких.
ppps: А может мы вообще не так что-то понимаем? Опять же конкретика спасёт отца РД.
Не только одной конторы опыт и не только мой. Основной труд: Кент Бек. Экстремальное программирование: разработка через тестирование. Ну и всех читать, понемногу, что есть эволюционное проектирование. Статьи Фаулера, книгу его «Рефакторинг: улучшение существующего кода». И т.д.
«При вас сказать UML — это высшей степени грех?»
А чего ж не грех. ЮМЛ, как диаграммы классов — это хорошая вещь для высокоуровневой документации (но даже для этого они не обязательны). Для кодирования и проектирования архиплохая вещь. Напомню один из главных принципов ООП (и не только ООП): инкапсуляция. Человеческий мозг так устроен, что умеет удерживать во внимании одновременно от 3 до 7 объектов (не ООП-объектов, а вообще). Инкапсуляцию придумали, чтобы на каждом уровне человек концентрировался на таком небольшом числе объектов, имеющих хорошие названия, которые говорят сами за себя, что за ними спрятано и позволяют не концентрироваться на том, что за ними. Диаграммы классов — это то, что делает диаметрально противоположное — кишки и говно — всё на картинке и не прячется.
«думать наперёд — это то, что нас из обизяны сделало»
Подмена понятий. То, что вы в проектировании наперед называете думать, я называю — необоснованно фантазировать. Точные науки отличаются от ненаук тем, что опираются на объективную информацию и делают из нее вывод, пытаясь снизить до минимума собственные предположения или выдумки. TDD и есть такой прямой научный способ проектировать. Опираться на приходящую информацию от заказчика, которая обычно приходит всегда. Заказчик меняет требования, что-то добавляет. Также TDD позволяет разрабатывать по кусочкам, концентрируясь то на одной, то на другой вещи. Т.е. даже если у вас есть сразу много (все) требования, вы не обязаны сразу их все спроектировать, не написав ни строчки. Требования вводятся в код понемногу, меняя архитектуру благодаря рефакторингу. Но главное — архитектура рождается обоснованно из требований, а не из фантазий.
А «креативные» личности, коими не являются математики, физики и т.д., любят фантазировать. Заказчик требует коня, дает полцарства, креативщик ему рисует в лучшем случае зебру, а в конце проекта получается осел
«При вас сказать UML — это высшей степени грех?»
А чего ж не грех. ЮМЛ, как диаграммы классов — это хорошая вещь для высокоуровневой документации (но даже для этого они не обязательны). Для кодирования и проектирования архиплохая вещь. Напомню один из главных принципов ООП (и не только ООП): инкапсуляция. Человеческий мозг так устроен, что умеет удерживать во внимании одновременно от 3 до 7 объектов (не ООП-объектов, а вообще). Инкапсуляцию придумали, чтобы на каждом уровне человек концентрировался на таком небольшом числе объектов, имеющих хорошие названия, которые говорят сами за себя, что за ними спрятано и позволяют не концентрироваться на том, что за ними. Диаграммы классов — это то, что делает диаметрально противоположное — кишки и говно — всё на картинке и не прячется.
«думать наперёд — это то, что нас из обизяны сделало»
Подмена понятий. То, что вы в проектировании наперед называете думать, я называю — необоснованно фантазировать. Точные науки отличаются от ненаук тем, что опираются на объективную информацию и делают из нее вывод, пытаясь снизить до минимума собственные предположения или выдумки. TDD и есть такой прямой научный способ проектировать. Опираться на приходящую информацию от заказчика, которая обычно приходит всегда. Заказчик меняет требования, что-то добавляет. Также TDD позволяет разрабатывать по кусочкам, концентрируясь то на одной, то на другой вещи. Т.е. даже если у вас есть сразу много (все) требования, вы не обязаны сразу их все спроектировать, не написав ни строчки. Требования вводятся в код понемногу, меняя архитектуру благодаря рефакторингу. Но главное — архитектура рождается обоснованно из требований, а не из фантазий.
А «креативные» личности, коими не являются математики, физики и т.д., любят фантазировать. Заказчик требует коня, дает полцарства, креативщик ему рисует в лучшем случае зебру, а в конце проекта получается осел
А когда инженеры схемы рисуют (Э1, Э3) — это тоже «фантазировать»?)
Вы видели когда-нибудь математика, который рисует схемы? (не геометрия )))
У вас неверная аналогия. Причем это одна из главных проблем нашей индустрии. У меня когда-то тоже была такая аналогия, знаю ее корни. Причина — наше образование, которое варьируется от плохого, то крайне ужасного. Начинающие программисты думают, что создают «конструкции». Надо по языку преподавателям надавать и вообще поменять термины, а то они с толку сбивают. «Управляющие конструкции» — привет императивным языкам. Следующий неправильный термин «архитектрор» (ну и «девелопер»). Только каски одеть — и вперед проектировать. Такие начинающие программисты или проектировщики представляют разработку, как построение дома. Отсюда и глюки.
Например, проектируя дом, программист хочет быть еще и фокусником — удивить гостей. Например, он сделает лишнюю гостевую комнату. Как будет доволен заказчик! Хотя он это и не требовал, но наш главный фантазер то знает, как оно бывает )))
А аналогия должна быть другая — программирование — лингвистическая вещь. Не путайте с гуманитарной. Математика — тоже лингвистическая вещь. Т.е. язык программирования — язык выражения мыслей. Язык математики — язык выражения сложных математических мыслей. Программист — не строитель. Программист — переводчик. Чем лучше он знает свой язык программирования и чем теснее общается с заказчиком, изучая его язык, тем точнее будет перевод.
А когда между заказчиком и программистом появляются лишние звенья, вроде аналитиков-проектировщиков, не знающих языка программирования — перевод заметно ухудшается. ЮМЛ — это тоже язык (правда убогий, хоть может быть ИНОГДА нагляднее). Если требования переводить сразу на ЮМЛ, а потом на язык программирования — получим двойной перевод. Представьте, что нужно перевести с китайского на русский что-то. Но переводят не прямо, а через промежуточный язык. При этом даже не английский, а например, чукотский, в котором отсутствуют многие понятия (не ради оскорбления национальностей). Тогда и получается код, вроде «Твой дом труба шаталь».
Кстати, вы интуитивно и представляете как строительство, поэтому мост и инженеров упоминаете.
У вас неверная аналогия. Причем это одна из главных проблем нашей индустрии. У меня когда-то тоже была такая аналогия, знаю ее корни. Причина — наше образование, которое варьируется от плохого, то крайне ужасного. Начинающие программисты думают, что создают «конструкции». Надо по языку преподавателям надавать и вообще поменять термины, а то они с толку сбивают. «Управляющие конструкции» — привет императивным языкам. Следующий неправильный термин «архитектрор» (ну и «девелопер»). Только каски одеть — и вперед проектировать. Такие начинающие программисты или проектировщики представляют разработку, как построение дома. Отсюда и глюки.
Например, проектируя дом, программист хочет быть еще и фокусником — удивить гостей. Например, он сделает лишнюю гостевую комнату. Как будет доволен заказчик! Хотя он это и не требовал, но наш главный фантазер то знает, как оно бывает )))
А аналогия должна быть другая — программирование — лингвистическая вещь. Не путайте с гуманитарной. Математика — тоже лингвистическая вещь. Т.е. язык программирования — язык выражения мыслей. Язык математики — язык выражения сложных математических мыслей. Программист — не строитель. Программист — переводчик. Чем лучше он знает свой язык программирования и чем теснее общается с заказчиком, изучая его язык, тем точнее будет перевод.
А когда между заказчиком и программистом появляются лишние звенья, вроде аналитиков-проектировщиков, не знающих языка программирования — перевод заметно ухудшается. ЮМЛ — это тоже язык (правда убогий, хоть может быть ИНОГДА нагляднее). Если требования переводить сразу на ЮМЛ, а потом на язык программирования — получим двойной перевод. Представьте, что нужно перевести с китайского на русский что-то. Но переводят не прямо, а через промежуточный язык. При этом даже не английский, а например, чукотский, в котором отсутствуют многие понятия (не ради оскорбления национальностей). Тогда и получается код, вроде «Твой дом труба шаталь».
Кстати, вы интуитивно и представляете как строительство, поэтому мост и инженеров упоминаете.
>Кстати, вы интуитивно и представляете как строительство, поэтому мост и инженеров упоминаете.
Мимо. Занятно видеть как проваливаются попытки «психологического анализа». Иногда сигара — просто сигара, помните?
Я инженер, эмбеддер, поэтому и задал вам вопрос про схемы. На который вы, кстати, не ответили. Это была не аналогия.
Мимо. Занятно видеть как проваливаются попытки «психологического анализа». Иногда сигара — просто сигара, помните?
Я инженер, эмбеддер, поэтому и задал вам вопрос про схемы. На который вы, кстати, не ответили. Это была не аналогия.
Это не психологический анализ, а факт. Вы стоите на позиции проектирования на перед. И сначала упоминаете мост, как аналогию, потом инженера.
О, так у вас и галлюцинации, не в обиду вам будет сказано.
Я в своем комментарии из одной фразы в упор не вижу слова «мост». Но вижу обозначения электрических схем — принципиальной и структурной. Вам часто доводилось видеть принципиальную схему моста?)
Повторю, на всякий случай, другими словми:
Я инженер. Да, знаете, из тех, что вы в каске представляете. Я делаю электронно-вычислительные устройства (это такие штуки, которые выполняют ваши «лингвистические вещи».) Мы рисуем схемы (Э1, Э2, Э3 — вот эти, например, наиболее распространены. Бывают и другие). Мой вопрос вам был такой: рисование этих схем — это тоже «фантазирование»? Может быть, нужно втыкать по микросхеме в макетку и ждать, пока тест выполнится?
Я в своем комментарии из одной фразы в упор не вижу слова «мост». Но вижу обозначения электрических схем — принципиальной и структурной. Вам часто доводилось видеть принципиальную схему моста?)
Повторю, на всякий случай, другими словми:
Я инженер. Да, знаете, из тех, что вы в каске представляете. Я делаю электронно-вычислительные устройства (это такие штуки, которые выполняют ваши «лингвистические вещи».) Мы рисуем схемы (Э1, Э2, Э3 — вот эти, например, наиболее распространены. Бывают и другие). Мой вопрос вам был такой: рисование этих схем — это тоже «фантазирование»? Может быть, нужно втыкать по микросхеме в макетку и ждать, пока тест выполнится?
А, извините, про мост писали не вы.
Но не суть важно. Проектирование мостов или электрических схем одинаково антианалогично к проектированию ПО. ПО, как и математика — язык выражения мыслей, а не модель из камня, бумаги или что-то, что будет потом реализовано в чем-то другом, материальном.
К программированию это не относится. Написать на языка ЮМЛ, а потом переписывать на другой язык не имеет смысла. Это не создание материального продукта. Но к сожалению, большинство так себе процесс и представляют. Сначала проектируем на чем-то «удобном для проектирования», а потом даем кому-то писать на страшном непонятном языке программирования. Строя дом или мост, конечно же, рефакторить не получится. Или когда схема появится, перепаивать ее дорого.
Но программа — это не пластилин, не кремний и не бетон. Она и есть описание, а не материальный объект.
Но не суть важно. Проектирование мостов или электрических схем одинаково антианалогично к проектированию ПО. ПО, как и математика — язык выражения мыслей, а не модель из камня, бумаги или что-то, что будет потом реализовано в чем-то другом, материальном.
К программированию это не относится. Написать на языка ЮМЛ, а потом переписывать на другой язык не имеет смысла. Это не создание материального продукта. Но к сожалению, большинство так себе процесс и представляют. Сначала проектируем на чем-то «удобном для проектирования», а потом даем кому-то писать на страшном непонятном языке программирования. Строя дом или мост, конечно же, рефакторить не получится. Или когда схема появится, перепаивать ее дорого.
Но программа — это не пластилин, не кремний и не бетон. Она и есть описание, а не материальный объект.
Схема тоже описание. До того как она появится в текстолите/кремнии.
Вас в крайности бросает, UML я сам не люблю, но высказывания в духе «проетирование = фантазирование» безосновательны, проектирование это не только переливание из пустого в порожнее посредством UML.
Это еще и разработка архитектуры, которую, так же как и в случае со схемой, менять будет долго и больно, а костыли рано или поздно перестанут помогать и зашатаются, если не предусмотреть какой-нибудь важный момент.
Вас в крайности бросает, UML я сам не люблю, но высказывания в духе «проетирование = фантазирование» безосновательны, проектирование это не только переливание из пустого в порожнее посредством UML.
Это еще и разработка архитектуры, которую, так же как и в случае со схемой, менять будет долго и больно, а костыли рано или поздно перестанут помогать и зашатаются, если не предусмотреть какой-нибудь важный момент.
Очень кратко я описал процесс ТДД здесь: ТДД
Нужно соблюдать процесс. Не я в крайности бросаюсь, а скорее вы, когда думаете, что есть выбор только одного из двух: «проектирование наперед» <-> «костыли».
Рефакторинг в ТДД гарантированно убирает костыли. Как раз наоборот получается. При небольших итерациях программист каждый раз «за собой подметает», исключая любой костыль.
Нужно соблюдать процесс. Не я в крайности бросаюсь, а скорее вы, когда думаете, что есть выбор только одного из двух: «проектирование наперед» <-> «костыли».
Рефакторинг в ТДД гарантированно убирает костыли. Как раз наоборот получается. При небольших итерациях программист каждый раз «за собой подметает», исключая любой костыль.
Вы что-то все вместе намешали. Желание разработчика сделать то, чего нет в требованиях, безусловно, неправильно, но какое это имеет отношение к построению схем, прототипированию и т.д?
Нарисовать wireframes для того, чтобы дизайнеру было проще рисовать пользовательский интерфейс — тоже лишнее?
Нарисовать схему данных прежде чем создавать ее — кому мешает?
А если над проектом работает несколько программистов, архитектор должен сесть и сперва сам всю логику написать или же можно обрисовать видение архитектуры, и далее поручить разные куски разным людям?
Если уж вам нравится сравнение с языком, то представьте, что автор романа сперва садится и составляет схему взаимоотношений героев между собой (кто кому кем приходится, когда родился, когда пересеклись и т.д.), чтобы в процессе написания текста самому не запутаться и не допустить ошибку.
Нарисовать wireframes для того, чтобы дизайнеру было проще рисовать пользовательский интерфейс — тоже лишнее?
Нарисовать схему данных прежде чем создавать ее — кому мешает?
А если над проектом работает несколько программистов, архитектор должен сесть и сперва сам всю логику написать или же можно обрисовать видение архитектуры, и далее поручить разные куски разным людям?
Если уж вам нравится сравнение с языком, то представьте, что автор романа сперва садится и составляет схему взаимоотношений героев между собой (кто кому кем приходится, когда родился, когда пересеклись и т.д.), чтобы в процессе написания текста самому не запутаться и не допустить ошибку.
Вы что-то все вместе намешали. Желание разработчика сделать то, чего нет в требованиях, безусловно, неправильно, но какое это имеет отношение к построению схем, прототипированию и т.д?
Наверное, не понятно выразил мысли. Конечно, проектирование само по себе не имеет отношения к вопросу, проектируется ли что-то лишнее.
Но что есть проектирование? Есть элементарное непонимание простых философских вещей (не люблю это слово). Программа — это не материальный объект, а идеальный. По Платону. Непонимая разницы, интуитивно, большинство представляет разработку аналогично другим видам деятельности (строительству, построению электрических схем, космических кораблей, автомобилей). В тех видах деятельности перед построением материального объекта предшествует построение идеального объекта. Чертеж поезда — идеальный объект (не чернила, не бумага, а именно смысл чертежа). Чертеж поезда — это описание. А поезд — материальный объект, который создается по чертежу. Вот, люди проводят параллель и думают, что это же будет в разработке — сначала чертеж (UML — «язык описаний»), потом материальный объект — программа. Вот где ошибка. Программа — не материальный объект, программа — это тоже описание. Т.е. при «проектировании» проводится лишняя работа. Мало того, та работа неэффективна. Потому что схемы не компилируются, схемы не покрываются тестами и их нельзя никаким образом измеримо связать с требованиями. Потом — схемы ущербнее современных языков программирования. Не позволяют выразить многие конструкции. Схемы также менее понятны, потому что они не скрывают то, что должны скрывать.
Недавно меня попросили нарисовать блок-схемы по коду. Вот это были комиксы! Код на 10-15 строчек, простой на вид, не помещался на лист формата А4. Вот бы кому-то показать, чтобы поняли, что картинки далеко не всегда нагляднее.
Код является альфой и омегой проекта. Именно код компилируется. Именно он выполняется, а не схемы. Именно в нем пишутся баги. Поэтому ОН ПЕРВИЧЕН. Код может быть непонятным. Но! Это не знак того, что нужна другая документация. В первую очередь это сигнал, что код непонятный и нужно его делать понятным. Потому что с непонятностью кода и коррелируют баги, тяжелая поддержка и развитие проекта.
То же относится к комментариям. Недавно мне принесли код, попросили что-то сделать с ним и поставить кругом комментарии. Я отказался ставить комментарии.
Весь код и так был в комментариях. Такого вида:
for (int i = 0; i < Bound_3; i++) // i is iterator of Month Dimension
И переменные везде: i, j, k, m, n и т.д… С подробными комментариями, что за переменные (код буквально зеленый от них).
Рефакторю сходу так:
for (int monthIndex = 0; i < monthCount; i++) // monthIndex is iterator of Month Dimension
Спрашиваю:
— Теперь нужен там комментарий, как думаете?
— Нет
Почему в среде разработчиков к коду относятся как к неродному сыну? Почему люди уверены, что хороший стиль — это делать всё что угодно кроме кодирования, только не заниматься улучшением кода? Почему вы думаете, что код должен быть последним, к чему прикасаются руки?
Нарисовать схему данных прежде чем создавать ее — кому мешает?
Мешает. Нарисовать схему и создать схему — это одно и то же. Если вы рисуете каким-то инструментом и он не порождает скрипт — вы удваиваете время на разработку. Во вторых — нарисовать СРАЗУ схему — не всегда получается. Многое можно не учесть. При этом — это нормальная ситуация и даже правильная. Проектировать надо параллельно с кодированием, потому что в процессе выясняются нюансы. И в таком процессе можно не сношать свое воображение до безобразия, стараясь выиграть войну в трехтысячном году, а переходить от одной части требований к другим постепенно. Почему многие думают, что правильно — не прикасаться к разработке, пока не представят себе всё? Это не имеет никакого, вообще никакого, объективно обоснованного смысла. Есть люди, ищущие трудности на ровном месте. Может хватит мазоаскетизмом заниматься?
В вашем изложении получается, что код — это такая магическая штука, волшебная :) А схемы — это трата времени в лучшем случае, в худшем — разрушитель волшебства.
Между тем, язык — это все-таки инструмент, и он вторичен. Логика — первична. А чем ее описывать — блок-схемой, uml-диаграммой или базовым языком — дело десятое. Важно лишь, чтобы все участники процесса поняли о чем идет речь, увидели целостную картину. Потому что когда у меня требований к системе — 200 страниц, в команде дизайнер-верстальщик, три фронт-ендщика (php), три бэк-ендщика (java), еще парочка специалистов работающих на другой половине земного шара, я, конечно, могу каждого попросить просто начать писать код. Но, боюсь, я потом их куски друг с другом не состыкую.
Между тем, язык — это все-таки инструмент, и он вторичен. Логика — первична. А чем ее описывать — блок-схемой, uml-диаграммой или базовым языком — дело десятое. Важно лишь, чтобы все участники процесса поняли о чем идет речь, увидели целостную картину. Потому что когда у меня требований к системе — 200 страниц, в команде дизайнер-верстальщик, три фронт-ендщика (php), три бэк-ендщика (java), еще парочка специалистов работающих на другой половине земного шара, я, конечно, могу каждого попросить просто начать писать код. Но, боюсь, я потом их куски друг с другом не состыкую.
Правильно меня поняли! Код, это не просто магическая штука, это единственная штука, которая РЕШАЕТ проблемы. Все остальные штуки — вторичные. Они имеют место быть, но только после того, когда никак не получилось в коде хорошо выразить.
Толку выражать логику в картинках. Она в картинках не работает. Потом, при любом рефакторинге — текст и картинки можно выбрасывать. Названия классов, методов поменялись.
Логика первична. И она в коде как раз должна быть. Язык — не только инструмент. Язык — это не молоток, язык — это язык (т.е. средство выражения мыслей, а не средство строителя и средство плотника). ЮМЛ — тоже язык. Качественно эти вещи не отличаются. Беда в том, что существуют люди, случайно забредшие в отрасль программирования и которые считают, что язык программирования не для выражения логики, и инструмент чернорабочих. Тогда и код получается чернорабочий.
Другое дело, если хороший программист умеет излагать мысли на языке программирования. Поэтому, ему надо только мысль передать — т.е. требования. А не конструкции, сделанные на промежуточном языке.
Да, код может быть сложным и по нему тяжело в логике разобраться и что хотели в нем написать. Так в этом же и есть проблема: в конкретном коде. Лечить надо код. Причину. А не скрывать проблему за ЮМЛ диаграммами.
Толку выражать логику в картинках. Она в картинках не работает. Потом, при любом рефакторинге — текст и картинки можно выбрасывать. Названия классов, методов поменялись.
Логика первична. И она в коде как раз должна быть. Язык — не только инструмент. Язык — это не молоток, язык — это язык (т.е. средство выражения мыслей, а не средство строителя и средство плотника). ЮМЛ — тоже язык. Качественно эти вещи не отличаются. Беда в том, что существуют люди, случайно забредшие в отрасль программирования и которые считают, что язык программирования не для выражения логики, и инструмент чернорабочих. Тогда и код получается чернорабочий.
Другое дело, если хороший программист умеет излагать мысли на языке программирования. Поэтому, ему надо только мысль передать — т.е. требования. А не конструкции, сделанные на промежуточном языке.
Да, код может быть сложным и по нему тяжело в логике разобраться и что хотели в нем написать. Так в этом же и есть проблема: в конкретном коде. Лечить надо код. Причину. А не скрывать проблему за ЮМЛ диаграммами.
Мне не очень понятно, почему рефакторинг вдруг меняет логику программы? (Выходит, изначально логика не была хорошо продумана, и пришлось не просто код рефакторить, а именно что логику менять?)
Названия классов и методов, после того как сменились, меняют логику программы??
Что-то вы очень странное пишете.
Названия классов и методов, после того как сменились, меняют логику программы??
Что-то вы очень странное пишете.
Названия в нашем деле самое главное ))) Как корабль назовешь, так он и плывет.
Я ж никак не могу достучаться — язык программирования — это язык, а не кирпичи. Им не строят, им выражают смысл. Основная вещь, позволяющая абстрагироваться — правильные названия.
Когда вам говорю в естественном языке слово «стол», сразу становится понятно, о чем я говорю. Я не рассказываю вам море информации — что я подразумеваю поверхность с несколькими ножками, на которой можно раскладывать еду, или поставить компьютер, что это предмет мебели, что ножек чаще всего 4, но иногда может быть меньше и т.д. и т.п.
Названия методов, классов, должны как можно четче выражать суть, иначе такие абстракции будут не помогать, а мешать.
«Названия классов и методов, после того как сменились, меняют логику программы??»
Я говорил про изменение названий не в смысле изменения логики, а в смысле — картинки выбрасываете. Потому что если на картинке одни названия, а в коде другие — очевидно, картинка уже не соответствует коду и уже не поможет новым разработчикам понять, что в коде, а наоборот.
«Выходит, изначально логика не была хорошо продумана, и пришлось не просто код рефакторить, а именно что логику менять?»
Постоянно и такое бывает. У вас не бывало? ))
Как факт, как неизменный — всё течет, всё меняется, такова река жизни. И логика не продумывается раз и навсегда. Мало того, я даже уверен, что так и правильно. Пару дней назад я набрасывал архитектуру одной вещи. Конечно, не делал рисунки, а прямо в базе строил прототип (код) и таблицы. Я знаю, что в трех таблицах еще нет определенных колонок, которые будут указывать состояние одного процесса, который обязан быть в проекте. Но я еще этот процесс не моделировал, код прототипа не писал. И поэтому, хотя я знаю, что они должны быть, я специально их не добавляю.
Это дзен. Придет время, придет и необходимость. Планировать наперед — это не дзен, это истерия ))
Повторю, не в обиду вам и не лично о вас. Замечена мною такая штука: «водопадная игла». Люди, как наркоманы. Когда на нее сели, каждый раз происходят неудачи. Каждый раз они не могут предугадать наперед, что случится. Каждый раз затягивается проект. И каждый раз они делают один и тот же вывод: «недостаточное планирование». Считают (как болезнь какая-то): вот в следующий раз мы уже точно сделаем идеальный проект. Надо только лучше планировать.
Ага, логика изначально плохо продумана. Только специально это можно делать, чтобы продумывать ее тогда, когда для этого пришло время и больше информации
Я ж никак не могу достучаться — язык программирования — это язык, а не кирпичи. Им не строят, им выражают смысл. Основная вещь, позволяющая абстрагироваться — правильные названия.
Когда вам говорю в естественном языке слово «стол», сразу становится понятно, о чем я говорю. Я не рассказываю вам море информации — что я подразумеваю поверхность с несколькими ножками, на которой можно раскладывать еду, или поставить компьютер, что это предмет мебели, что ножек чаще всего 4, но иногда может быть меньше и т.д. и т.п.
Названия методов, классов, должны как можно четче выражать суть, иначе такие абстракции будут не помогать, а мешать.
«Названия классов и методов, после того как сменились, меняют логику программы??»
Я говорил про изменение названий не в смысле изменения логики, а в смысле — картинки выбрасываете. Потому что если на картинке одни названия, а в коде другие — очевидно, картинка уже не соответствует коду и уже не поможет новым разработчикам понять, что в коде, а наоборот.
«Выходит, изначально логика не была хорошо продумана, и пришлось не просто код рефакторить, а именно что логику менять?»
Постоянно и такое бывает. У вас не бывало? ))
Как факт, как неизменный — всё течет, всё меняется, такова река жизни. И логика не продумывается раз и навсегда. Мало того, я даже уверен, что так и правильно. Пару дней назад я набрасывал архитектуру одной вещи. Конечно, не делал рисунки, а прямо в базе строил прототип (код) и таблицы. Я знаю, что в трех таблицах еще нет определенных колонок, которые будут указывать состояние одного процесса, который обязан быть в проекте. Но я еще этот процесс не моделировал, код прототипа не писал. И поэтому, хотя я знаю, что они должны быть, я специально их не добавляю.
Это дзен. Придет время, придет и необходимость. Планировать наперед — это не дзен, это истерия ))
Повторю, не в обиду вам и не лично о вас. Замечена мною такая штука: «водопадная игла». Люди, как наркоманы. Когда на нее сели, каждый раз происходят неудачи. Каждый раз они не могут предугадать наперед, что случится. Каждый раз затягивается проект. И каждый раз они делают один и тот же вывод: «недостаточное планирование». Считают (как болезнь какая-то): вот в следующий раз мы уже точно сделаем идеальный проект. Надо только лучше планировать.
Ага, логика изначально плохо продумана. Только специально это можно делать, чтобы продумывать ее тогда, когда для этого пришло время и больше информации
Не только одной конторы опыт и не только мой.
И всё-таки? Тов. Бек это хорошо, но мне интересен тот, который вызывает в вас конкретно лютую н-сть.
Для кодирования и проектирования плохая вещь
Дык телескопом гвозди забивать плохо — здесь я не спорю. Но вообще без него плохо.
То, что вы в проектировании наперед называете думать, я называю — необоснованно фантазировать.
Эээ… Фантазировать вообще плохо — это везде написано. Не заказано? Не фиг учитывать. Это же стандартная болезнь «а вдрук?» Вдруг бывает только пук. И фантазёры везде возможны — что в постановке, что в проектировании, что в девелопменте. Конкретная стадия создания продукта не является прибежищем фантазмов. Я вполне если фантазер, могу и в TDD нафантазировать — вот запросто.
креативщик ему рисует в лучшем случае зебру
Дык и надо креативщика пытать и не принимать от него ASIS. Пытать вышестоящих, что нарисована/написана зебра. Btw, а мы не путаем постановку и проектирование? По ходу по вашим словам у нас проектирования вааще нет, а только голая необработанная постановка подаётся как результат проектирования: типа пишите и нииbird. Здесь тогда конкретный процесс виноват — м.б. в вашей конторе (-ах) или в российской индустрии в-принципе.
ps: У меня щас нет под рукоё тов. Бека. У вас нету его? Там из предисловия выцепить его опыт — где работал, на каких ролях что делал и почему just TDD лучше чем проектирование + ANY-driven-development? TDD я за, но не сторонник утверждения, что «blabla-DD только и ничего больше спасёт мир!!!»
Даже если вы не фантазер, вы берете за основу процесс фантазирования.
А если так:
1. Требование -> тест
2. Проверям тесты -> падает последний. Убедились, что требование не реализованно.
3. Пишем код, запускаем тест, требование удовлетворено.
4. Рефакторинг кода, пока он не станет самым простым и естественным. И чтобы тесты не падаел.
5. Идем в пункт 1.
Если много требований, то берем по одному. Если требования слишком высокоуровневые, добавляем от себя подтребования и по тому же алгоритму.
А что предлагает проектирование наперед? Рефлексировать на тему красоты и гибкости? Где в проектировании наперед есть объективная составляющая? Критериев оценки там нет. (И поверьте опыту — водопад всегда затягивает проекты и получается говнокод в итоге. Жаль, что водопадная игла заставляет людей не видеть причину, а списывать на плохое планирование и стараться в следующий раз «планировать тщательнее»)
А если так:
1. Требование -> тест
2. Проверям тесты -> падает последний. Убедились, что требование не реализованно.
3. Пишем код, запускаем тест, требование удовлетворено.
4. Рефакторинг кода, пока он не станет самым простым и естественным. И чтобы тесты не падаел.
5. Идем в пункт 1.
Если много требований, то берем по одному. Если требования слишком высокоуровневые, добавляем от себя подтребования и по тому же алгоритму.
А что предлагает проектирование наперед? Рефлексировать на тему красоты и гибкости? Где в проектировании наперед есть объективная составляющая? Критериев оценки там нет. (И поверьте опыту — водопад всегда затягивает проекты и получается говнокод в итоге. Жаль, что водопадная игла заставляет людей не видеть причину, а списывать на плохое планирование и стараться в следующий раз «планировать тщательнее»)
Мы так и не увидели конкретики и опыта.
У меня есть положительный опыт как с проектированием, так и без него, как с TDD, так и без него.
Т.к. проектирование есть процесс, от которого зависит разработка, то мне очевидно, что у вас был отрицательный опыт из-за того, что процесс был криво поставлен и проектирования либо реально не было, либо вы понимаете под проектированием то, что является постановкой.
Но опять же мне мало интересны догадки — вы правильно заметили, что факты всем правят. Если вы их скрываете, значит либо их нет, либо они не подтверждают одни из ваших тезисов.
Пока мы не видим конкретики и деталей опыта — это всё похоже просто на крики чаек и сотрясание воздуха, аргументы ни о чём и обо всём.
У меня есть положительный опыт как с проектированием, так и без него, как с TDD, так и без него.
Т.к. проектирование есть процесс, от которого зависит разработка, то мне очевидно, что у вас был отрицательный опыт из-за того, что процесс был криво поставлен и проектирования либо реально не было, либо вы понимаете под проектированием то, что является постановкой.
Но опять же мне мало интересны догадки — вы правильно заметили, что факты всем правят. Если вы их скрываете, значит либо их нет, либо они не подтверждают одни из ваших тезисов.
Пока мы не видим конкретики и деталей опыта — это всё похоже просто на крики чаек и сотрясание воздуха, аргументы ни о чём и обо всём.
Аргументы ничего не значат? Что такое объективно, что такое субъективно — это вроде должно объясняться логически.
Вроде этого:
Точные науки рождают представления об объективном мире (знания):
Объективный мир -> Субъект -> Представление об мире.
Не науки поступают так:
Объективный мир < — Субъект -> Представление об мире.
Стрелки — это информационные потоки. Субъективный вымысел называется творчеством.
Угадайте, какой рисунок в проектировании наперед?
Заказчик (объект) < — (угадаем что ему нужно) < — Проектировщик (субъект) -> Программа (делает непонятно что непонятно кому нужно)
Опыт описать кратко не получится. Любой проект, даже небольшой всегда тянет на книгу, потому что каждый день происходит что-то интересное.
Могу кинуть ссылку, не в целях рекламы, своей статьи, косвенно показывающей, как можно и почему выгодно проектировать эволюционно: Хлеб Маркуса и YAGNI
Вроде этого:
Точные науки рождают представления об объективном мире (знания):
Объективный мир -> Субъект -> Представление об мире.
Не науки поступают так:
Объективный мир < — Субъект -> Представление об мире.
Стрелки — это информационные потоки. Субъективный вымысел называется творчеством.
Угадайте, какой рисунок в проектировании наперед?
Заказчик (объект) < — (угадаем что ему нужно) < — Проектировщик (субъект) -> Программа (делает непонятно что непонятно кому нужно)
Опыт описать кратко не получится. Любой проект, даже небольшой всегда тянет на книгу, потому что каждый день происходит что-то интересное.
Могу кинуть ссылку, не в целях рекламы, своей статьи, косвенно показывающей, как можно и почему выгодно проектировать эволюционно: Хлеб Маркуса и YAGNI
Статья прекрасна, но это не факты. Вы сами в своём комменте писали:
Gimme факты! Давайте конкретику разбирать, а не абстрактныхконей хлебов в вакууме!
Точные науки отличаются от ненаук тем, что опираются на объективную информацию и делают из нее вывод, пытаясь снизить до минимума собственные предположения или выдумки
Gimme факты! Давайте конкретику разбирать, а не абстрактных
Лично меня устраивает то, что я написал в статье. Не такой хлеб и абстрактный в вакууме.
А бОльшую конкретику обсуждать не имею никакой возможности. Потому что объем текста будет гораздо больше статей.
А потом, просто аргументов в разговоре должно быть достаточно. Или хотя бы аналогий. Почему ТДД выгодно, уже несколько раз написал, под раз написал здесь под несколькими углами. А от вас не услышал ни одного аргумента, что выгодно проектировать наперед. Кроме того, что у вас есть положительный опыт. И вы после этого требуете от меня описания моего опыта, потому что не верите в мой опыт? Ну тогда я умею очень хорошо притворяться, что даже аргументы выдумываю на ходу логичные.
А бОльшую конкретику обсуждать не имею никакой возможности. Потому что объем текста будет гораздо больше статей.
А потом, просто аргументов в разговоре должно быть достаточно. Или хотя бы аналогий. Почему ТДД выгодно, уже несколько раз написал, под раз написал здесь под несколькими углами. А от вас не услышал ни одного аргумента, что выгодно проектировать наперед. Кроме того, что у вас есть положительный опыт. И вы после этого требуете от меня описания моего опыта, потому что не верите в мой опыт? Ну тогда я умею очень хорошо притворяться, что даже аргументы выдумываю на ходу логичные.
http://lurkmore.to/Сферический_конь_в_вакууме
Без фактов ваши «поганые мётлы» вглядят пусто. Если вам не повезло с процессом, то это не значит, что так делать не надо — это единственная догадка, которую можно сделать.
Я не собираюсь аргументировать — изначальное заявление о мётлах от вас пошло и пока вы его не обоснуете — оно пусто. Прекрасная статья — лишь асбтрактный конь в вакууме, не более того — это просто художественный вымысел.
Без фактов ваши «поганые мётлы» вглядят пусто. Если вам не повезло с процессом, то это не значит, что так делать не надо — это единственная догадка, которую можно сделать.
Я не собираюсь аргументировать — изначальное заявление о мётлах от вас пошло и пока вы его не обоснуете — оно пусто. Прекрасная статья — лишь асбтрактный конь в вакууме, не более того — это просто художественный вымысел.
И ещё — я не противник TDD или иных практик, которые положительны для вас и нас.
Я — противник общих утверждений, исходящих из частностей конкретных опытов.
Я — противник общих утверждений, исходящих из частностей конкретных опытов.
Есть огромное количество задач, где TDD не работает. Не вся разработка крутится вокруг требований и фич, которые можно описать как user story.
TDD не обязательно опираться должно на user story. Последнее — хорошо и прекрасно для многих проектов. Но ТДД — это процесс разработки, а не обязательно процесс преобразования требований от заказчика.
Я, например, сейчас делаю дома один проект. Математические вычисления, большие объемы данных. Заказчика нет, я сам себе заказчик. Юзер-стори тоже нет, даже гуи-интерфейса пока нет, т.к. гуи-интерфейс далеко не связан с сутью проекта. Нет сущностей.
Но ТДД прекрасно работает. Требование в ТДД — это требование к следующему шагу кодирования. Не обязательно требование заказчика.
Скажу даже больше: на выходных я провел за полдня рефакторинг, который затронул почти весь код. И понял, что без того покрытия тестами уже проект бы умер. Но с тестами вообще практически без никаких рисков такие масштабные изменения.
Конечно, юнит-тесты не являются показателем, что проект по ТДД разрабатывается. Но всё же в этом проекте я бы не смог без него разрабатывать.
Если проект такого плана, что архитектура не может родиться сама по себе из кода, то тогда делают прототипы. Выбирают подходящий. На этапе прототипирования не покрывают тестами а оценивают только, какой подход будет более подходящим. А потом переписывание на чистовик — с ТДД. И в этом нет никакого минуса. Если вы собираетесь писать тест, то лучше его написать до, чем после. Во первых, виднее, какого размера код на метод выделить (как его удобнее тестировать). Во вторых не сидите в дебаге так много, проверяя, что не так, если тест есть. В третьих не забудете тест написать и покрытие при ТДД обычно более полное.
Я, например, сейчас делаю дома один проект. Математические вычисления, большие объемы данных. Заказчика нет, я сам себе заказчик. Юзер-стори тоже нет, даже гуи-интерфейса пока нет, т.к. гуи-интерфейс далеко не связан с сутью проекта. Нет сущностей.
Но ТДД прекрасно работает. Требование в ТДД — это требование к следующему шагу кодирования. Не обязательно требование заказчика.
Скажу даже больше: на выходных я провел за полдня рефакторинг, который затронул почти весь код. И понял, что без того покрытия тестами уже проект бы умер. Но с тестами вообще практически без никаких рисков такие масштабные изменения.
Конечно, юнит-тесты не являются показателем, что проект по ТДД разрабатывается. Но всё же в этом проекте я бы не смог без него разрабатывать.
Если проект такого плана, что архитектура не может родиться сама по себе из кода, то тогда делают прототипы. Выбирают подходящий. На этапе прототипирования не покрывают тестами а оценивают только, какой подход будет более подходящим. А потом переписывание на чистовик — с ТДД. И в этом нет никакого минуса. Если вы собираетесь писать тест, то лучше его написать до, чем после. Во первых, виднее, какого размера код на метод выделить (как его удобнее тестировать). Во вторых не сидите в дебаге так много, проверяя, что не так, если тест есть. В третьих не забудете тест написать и покрытие при ТДД обычно более полное.
Не совсем правильно выразился — не «не работает», а «не эффективно».
На прототипирование я и намекаю. Что это как не предварительное черновое проектирование?
На прототипирование я и намекаю. Что это как не предварительное черновое проектирование?
Прототипирование тяжело назвать проектированием. Цель прототипа — не создать архитектуру, а проверить какой-либо подход, модель.
Часто прототипирование делают на функциональных языках, где понятие «архитектура» слабо применимо.
Обычно прототип — это наспех слепленная каша из кода, которого минимум, лишь бы что-то оценить. При прототипировании нет никаких правил проектирования. Также и нет запрета на эволюционное проектирование. Я и прототипы в чуть более сложных проектах развиваю эволюционно. Сначала пишется самая существенная часть функционала в прототипе. Потом добавляю то, что менее существенное.
Часто прототипирование делают на функциональных языках, где понятие «архитектура» слабо применимо.
Обычно прототип — это наспех слепленная каша из кода, которого минимум, лишь бы что-то оценить. При прототипировании нет никаких правил проектирования. Также и нет запрета на эволюционное проектирование. Я и прототипы в чуть более сложных проектах развиваю эволюционно. Сначала пишется самая существенная часть функционала в прототипе. Потом добавляю то, что менее существенное.
добавляем от себя подтребования
То есть фантазируем? Имхо, в нормально организованном TDD тоже есть фаза проектирования — называется «уточнение, детализация и формализация требований заказчика». И «рисунки» на этом этапе вполне допустимы.
Кодирование — зло, рисунки зло еще большее. Всё, что мы делаем — плохо. Поэтому надо стараться сделать как можно меньше вреда.
Без кодирования, которое зло, нельзя написать никакой проект. Поэтому стараемся кодить как можно меньше и как можно проще. Это критерий наименьшего вреда в кодировании. И следовательно, где-то здесь экстремум того, какой наилучший дизайн (т.е. наименее худший).
Рисунки — зло. Рисуем и помним об этом. Поэтому рисуем только для хорошего взаимопонимания, не больше, не в визио, не т.д. При этом помним, что зло и пытаемся склонить заказчика к описанию словесному, по пунктам — т.е. юз-кейсам или юзерстори. Зачем, если есть рисунки? Потому что по рисункам не сдашь проект. По рисункам тесты не напишешь. А вот по четким юз-кейсам, описанным в виде утверждений — напишешь. Это настоящие требования, которые можно отразить в приемочных тестах.
А так, всё можно. Рисунки можно. Можно диаграммы классов. И вообще, нет никаких формальностей, как душе угодно. Единственное, критерии надо выработать. Я, например, считаю хорошим критерием — испытывать отвращение к коду, а значит к бОльшему его объему, к оверинженирингу, к не DRY (например, если проектировщик такой умный в юмл-диаграммах, то почему надо кому-то повторять работу? Пусть генерирует код из них. Или сам и пишет).
Я предлагаю перейти на другую сторону: не испытывать больше умиления от архитектуры и не искать красоты (и не дай бог гибкости). А считать, что наша деятельность — это повышение энтропии — и всеми силами с нею бороться.
Без кодирования, которое зло, нельзя написать никакой проект. Поэтому стараемся кодить как можно меньше и как можно проще. Это критерий наименьшего вреда в кодировании. И следовательно, где-то здесь экстремум того, какой наилучший дизайн (т.е. наименее худший).
Рисунки — зло. Рисуем и помним об этом. Поэтому рисуем только для хорошего взаимопонимания, не больше, не в визио, не т.д. При этом помним, что зло и пытаемся склонить заказчика к описанию словесному, по пунктам — т.е. юз-кейсам или юзерстори. Зачем, если есть рисунки? Потому что по рисункам не сдашь проект. По рисункам тесты не напишешь. А вот по четким юз-кейсам, описанным в виде утверждений — напишешь. Это настоящие требования, которые можно отразить в приемочных тестах.
А так, всё можно. Рисунки можно. Можно диаграммы классов. И вообще, нет никаких формальностей, как душе угодно. Единственное, критерии надо выработать. Я, например, считаю хорошим критерием — испытывать отвращение к коду, а значит к бОльшему его объему, к оверинженирингу, к не DRY (например, если проектировщик такой умный в юмл-диаграммах, то почему надо кому-то повторять работу? Пусть генерирует код из них. Или сам и пишет).
Я предлагаю перейти на другую сторону: не испытывать больше умиления от архитектуры и не искать красоты (и не дай бог гибкости). А считать, что наша деятельность — это повышение энтропии — и всеми силами с нею бороться.
Один раз пытался сдать проект «по утверждениям» — заказчик категорически не хочет подписывать утверждения вроде «кнопка ок должна находиться в 180 пикселах от низа окна браузера», говорит «дайте мне макет — я его подпишу, мне всё равно будет там 180 пикселей или 179, мне главное чтобы было удобно и красиво».
Правильно говорит. Фаза общения с заказчиком до утверждения требований, вообще-то, довольно размыта и вместе с заказчиком можете фантазировать, предлагать ему какие-то решения, которые он не предполагал, показывать макеты. После утверждения требований — всё строго — нет никаких больше требований, кроме утвержденных.
Исключения из правил тоже есть. Например, забыли утвердить, как должно выглядеть ГУИ. Можно писать какое угодно с пониманием, что эти вещи надо будет «доутвердить» и когда-то переделаются, возможно. Но работы над не утвержденными вещами, если без них не обойтись — должно быть минимум. Не нужно представлять себя фокусником и пытаться его удивить.
А предложить красивые макеты с вопросом, нравятся ли и включать ли их в проект — конечно правильно — это не расходится с процессом. Потом, я больше привык работать с проектами, в которых есть некоторая предметная область и есть какая-то суть работы. Графический интерфейс должен быть, а вот какой — это дело не всегда важное — поэтому заказчик может не спешить утверждать, где находится кнопка. Ему это просто может быть неинтересно.
Исключения из правил тоже есть. Например, забыли утвердить, как должно выглядеть ГУИ. Можно писать какое угодно с пониманием, что эти вещи надо будет «доутвердить» и когда-то переделаются, возможно. Но работы над не утвержденными вещами, если без них не обойтись — должно быть минимум. Не нужно представлять себя фокусником и пытаться его удивить.
А предложить красивые макеты с вопросом, нравятся ли и включать ли их в проект — конечно правильно — это не расходится с процессом. Потом, я больше привык работать с проектами, в которых есть некоторая предметная область и есть какая-то суть работы. Графический интерфейс должен быть, а вот какой — это дело не всегда важное — поэтому заказчик может не спешить утверждать, где находится кнопка. Ему это просто может быть неинтересно.
>например, если проектировщик такой умный в юмл-диаграммах, то почему надо кому-то повторять работу? Пусть генерирует код из них. Или сам и пишет
+1000
+1000
«Думать наперед, это равносильно «воображать» — удел гуманитариев.»
«Думать не надо, надо знать.»
Очень вас прошу, продолжайте в том же духе. Чем больше вас таких, тем ценнее я как специалист.
«Думать не надо, надо знать.»
Очень вас прошу, продолжайте в том же духе. Чем больше вас таких, тем ценнее я как специалист.
У вас метафора не верная. Мост строится один раз и не переделывается. Программы же по факту переделываются и дополняются постоянно.
Ды это грубая — главное не мост, а процесс: думаем, потом делаем.
Не. Хорошо, досконально продумать можно только когда мы точно знаем, что должны получить, не больше не меньше. В разработке ПО такого не бывает. Завтра требования могут измениться коренным образом, и всё, что надумали — будет неправильным. Я об этом писал.
Дык на определённый момент же мы это знаем? Знаем. Значит на определённый момент мы можем спроектировать, срисовать и т.д.
Проблема только в том, что после изменения требований надо обновлять не только участок разработки, но и проектирования! Вдолбите это в бошки менеджерам и будьте щастливы.
И да — этим должны отдельные умные (причем самые!) люди заниматься, а не студенты. Это условно говоря — матрёшка, тоже самое, что слои в архитектуре. У нас же не бывает, что мы слой данных обновили, а слой представления лежит как есть двухлетней давности?
Вбиваем в головы, что если и дают схемы, то не надо просто их брать, а проверять, ревьюить на адекватность или сразу говорить: «Сия схема — г-но, ибо тыдыщ и воттутдыть.»
Проблема только в том, что после изменения требований надо обновлять не только участок разработки, но и проектирования! Вдолбите это в бошки менеджерам и будьте щастливы.
И да — этим должны отдельные умные (причем самые!) люди заниматься, а не студенты. Это условно говоря — матрёшка, тоже самое, что слои в архитектуре. У нас же не бывает, что мы слой данных обновили, а слой представления лежит как есть двухлетней давности?
Вбиваем в головы, что если и дают схемы, то не надо просто их брать, а проверять, ревьюить на адекватность или сразу говорить: «Сия схема — г-но, ибо тыдыщ и воттутдыть.»
Я вот однажды осознал ситуацию, что код функционирует одним образом, а в головах менеджеров и на красивых схемах всё совсем по-другому. Программисты (я в том числе) пилили код как он есть, выдавая менеджерам информацию согласно их ожиданию, только чтобы не огорчать их. То есть время тратилось не только на работу, а ещё и на поддержание заблуждений управленцев.
А вот это уже плохо — мы таким образом не только управленцев, но и сами себя наёбываем. Всё таки лучше иногда яйки иметь и сказать ASIS. Это уже как раз задача ПМа. Если ПМ заблуждается — то это говно-ПМ, раз не может определить, что ему слегонца лгут.
Я ни в коем случае не за «всегда и везде красивые схемЫ!!11», а больше за адекватное разделение одно и другого. Если у вас этого нет — виновны ваши менеджеры. И они же дают вам говно-схемы, которые не актуальны. Именно они — их к стенке.
Я ни в коем случае не за «всегда и везде красивые схемЫ!!11», а больше за адекватное разделение одно и другого. Если у вас этого нет — виновны ваши менеджеры. И они же дают вам говно-схемы, которые не актуальны. Именно они — их к стенке.
+1000
Я ЗА ЖИВОЕ ПРОЕКТИРОВАНИЕ.
НО! Бесят и люди, которые все время хотят сделать идеально. Проектируют сто лет.
А потом жалуются, когда переделывать приходится.
А я ведь говорил
— сначала первые несколько итераций быстро, чтобы понять проблемы, на живых данных
— дальше уже проектируем норм архитектуру, рефакторим
— и так далее, эволюция
моя статья в тему
habrahabr.ru/post/126988/
см. в конце второго раздела
Я ЗА ЖИВОЕ ПРОЕКТИРОВАНИЕ.
НО! Бесят и люди, которые все время хотят сделать идеально. Проектируют сто лет.
А потом жалуются, когда переделывать приходится.
А я ведь говорил
— сначала первые несколько итераций быстро, чтобы понять проблемы, на живых данных
— дальше уже проектируем норм архитектуру, рефакторим
— и так далее, эволюция
моя статья в тему
habrahabr.ru/post/126988/
см. в конце второго раздела
Когда уже люди мозгами дойдут, что не может обычный программист нормально проанализировать бизнес заказчика, разрисовать бизнес-процессы, нарисовать пользовательские сценарии, спроектировать интерфейсы, красиво их нарисовать…
Рисунки, графики, схемы, диаграммы и т. п. один из самых оптимальных способов передачи информации между людьми, «говорящих на разных языках».
Рисунки, графики, схемы, диаграммы и т. п. один из самых оптимальных способов передачи информации между людьми, «говорящих на разных языках».
> желание сделать нечто такое, что один человек сделать не может в принципе.
Это верно только отчасти. Нисколько не умаляю важность управляющих должностей, но все таки, чем больше в должности от управленца, тем меньше в итоговом продукте он «сделает» с технической точки зрения. И когда инженеры (и тимлиды, главные инженеры) будут знать, как продукт работает, управленец уровнем выше уже будет иметь только поверхностное знание.
Поэтому я, допустим, не против управлять группой инженеров с технической точки зрения, но глубже в управление соваться совсем не хочется. Говорят, главный инженер — это инженер, который мог бы проект сделать и в одиночку. Вот это, на мой взгляд, оптимальное сочетание управленца и специалиста (тимлиды сюда же относятся).
Это верно только отчасти. Нисколько не умаляю важность управляющих должностей, но все таки, чем больше в должности от управленца, тем меньше в итоговом продукте он «сделает» с технической точки зрения. И когда инженеры (и тимлиды, главные инженеры) будут знать, как продукт работает, управленец уровнем выше уже будет иметь только поверхностное знание.
Поэтому я, допустим, не против управлять группой инженеров с технической точки зрения, но глубже в управление соваться совсем не хочется. Говорят, главный инженер — это инженер, который мог бы проект сделать и в одиночку. Вот это, на мой взгляд, оптимальное сочетание управленца и специалиста (тимлиды сюда же относятся).
Под сделать мы здесь понимаем скорее добиться цели, а не знать, как именно мы её добились.
Т.е. мне к примеру интересует «что сделать», заместо того «как сделать».
Даже если нас двое и я ноль в девелопменте, а другой человек — супер-девелопер и мы вместе добьемся цели, то я буду рад.
Под вместе я понимаю: защитить человека от внешней xyeты, подбадривать его если всё херово, мотивировать, контролировать, чтобы влево и вправо не убежать и в итоге успеть сделать то, что надо вовремя.
Именно за это ценятся управленцы и в это их соль. Управленец — папка, а сотрудник —мамка файл.
Управленец — nginx, wrapper, API, который даёт только нужное и держит в правильном направлении.
Он как мать гепардов — учит их кушать самостоятельно, защищает и делает щастливыми.
Т.е. мне к примеру интересует «что сделать», заместо того «как сделать».
Даже если нас двое и я ноль в девелопменте, а другой человек — супер-девелопер и мы вместе добьемся цели, то я буду рад.
Под вместе я понимаю: защитить человека от внешней xyeты, подбадривать его если всё херово, мотивировать, контролировать, чтобы влево и вправо не убежать и в итоге успеть сделать то, что надо вовремя.
Именно за это ценятся управленцы и в это их соль. Управленец — папка, а сотрудник —
Управленец — nginx, wrapper, API, который даёт только нужное и держит в правильном направлении.
Он как мать гепардов — учит их кушать самостоятельно, защищает и делает щастливыми.
нужен и архитектор, и тимлид, и ведущие программисты в группах, если вы делаете сложный проект несколькими группами
Хороших программистов мало, а управленцев — еще меньше.Ага: нас, программистов, было 4 группы. А параллельно с нами вгрызались в гранит науки 19 групп экономистов-управленцев… хаотично мигрируют от продаж стирального порошка к разработке программного обеспечения, при этом они искренне не видят разницы – не всё ли равно, чем руководить?… они делают карьеру – что, собственно, и является их основной и, подчас, единственной истинной «специализацией»
Хороших.
Ведь кто открыл учебник по HTML/CSS и стал «вебмастером» много. А суперверстальщиков — мало.
Они идут «по цене белужьей икры» (С) классная фраза из той статьи.
Ведь кто открыл учебник по HTML/CSS и стал «вебмастером» много. А суперверстальщиков — мало.
Они идут «по цене белужьей икры» (С) классная фраза из той статьи.
Ага. Причина №6: хороший понт дороже денег, вот и идут в менеджеры-хоть-чего-нибудь каждый второй.
— Эй, извозчик!
— Я не извозчик — яруководитель кобылы!
— Эй, извозчик!
— Я не извозчик — я
В целом согласен. Всегда забавно наблюдать, когда «рабочая сила» говорит, что начальник не нужен. Это значит менеджеры у большинства хорошие. Лошадь тоже думает, что извозчик не нужен, людей-то качать она и сама может.
Хотел бы только второй пункт усилить: 2500 лет назад Сунь Цзы написал хорошую методичку по управлению, и она актуальна до сих пор.
Хотел бы только второй пункт усилить: 2500 лет назад Сунь Цзы написал хорошую методичку по управлению, и она актуальна до сих пор.
На мой взгляд переход Программист -> Управленец — полная херня!
И что бы тут не говорили про масштабируемость ресурсов, делегирование задач и прочий корпоративный bull shit картина вырисовывается одна — мне надоело/я устал следовать за технологиями, хочу не кодить, а управлять, но за те же деньги или даже поболе. А реальность оказывается совсем другой, нифига не такой розовой как кажется со стороны программера.
Так вот, что я вам скажу, мои маленькие любители митингов — хотите управлять, масштабировать, рисковать и брать ответственность? Открывайте свой собственный бизнес! Делайте второй Microsoft/Apple/Google/Amazon, будьте джобсами/гейтсами/бринами, создавайте продукт, который будет полезен людям, придумывайте, рискуйте, нанимайте людей, которые будут бежать к вам на работу как на праздник, делайте мир лучше!
Там вам будет и ответственность, и риски, и бескрайние горизонты.
Ладно, пошел на очередной гребаный митинг, который на фиг мне не сдался, но менеджерам же надо всем показать как усердно они трудятся — полотра часа времени уйдет в мусор :(
И что бы тут не говорили про масштабируемость ресурсов, делегирование задач и прочий корпоративный bull shit картина вырисовывается одна — мне надоело/я устал следовать за технологиями, хочу не кодить, а управлять, но за те же деньги или даже поболе. А реальность оказывается совсем другой, нифига не такой розовой как кажется со стороны программера.
Так вот, что я вам скажу, мои маленькие любители митингов — хотите управлять, масштабировать, рисковать и брать ответственность? Открывайте свой собственный бизнес! Делайте второй Microsoft/Apple/Google/Amazon, будьте джобсами/гейтсами/бринами, создавайте продукт, который будет полезен людям, придумывайте, рискуйте, нанимайте людей, которые будут бежать к вам на работу как на праздник, делайте мир лучше!
Там вам будет и ответственность, и риски, и бескрайние горизонты.
Ладно, пошел на очередной гребаный митинг, который на фиг мне не сдался, но менеджерам же надо всем показать как усердно они трудятся — полотра часа времени уйдет в мусор :(
Я у себя выбросил ежедневные митинги, совещания и тд.
только при необходимости.
плюс у меня есть правило четырех часов тишины.
оттуда
>- ежедневно надо так распределять время, чтобы у программиста было не менее 4х часов «тихого» рабочего времени в это время он отключает скайп и аську, остается доступен только через почту и джаббер.
если бы все еще это юзали, но это другой вопрос:)
только при необходимости.
плюс у меня есть правило четырех часов тишины.
оттуда
>- ежедневно надо так распределять время, чтобы у программиста было не менее 4х часов «тихого» рабочего времени в это время он отключает скайп и аську, остается доступен только через почту и джаббер.
если бы все еще это юзали, но это другой вопрос:)
Есть менеджеры, которым «надо показать», что они трудятся. А есть менеджеры, которые реально решают проблемы, чтобы специалист не отвлекался и мог спокойно трудиться. И в этом есть свой кайф для менеджера. Когда до тебя что-то не работало, какой-то процесс, и люди раздражались, злились. Ну, например, лажает отдел QA, а плохо выглядят все — и аналитики, и программисты, и их линейное начальство. А тут пришел ты и «починил». И сразу столько людей осчастливил :) (ну, кроме уволенного тестировщика, бгг).
У меня друг — product manager, собирает требования, составляет ТЗ, пишет спеки и рисует прототипы форм. Работа его — нужная, полезная и неотъемлемая часть процесса разработки. Я с ним общаюсь по многу раз в день, уточняя детали и обсуждая проект. Такой менеджер — полезный человек для компании.
«Починщик» в вашм примере — балласт, который на хер никому не нужен. Именно они создают бесполезные митинги и бесконечные потоки е-мейлов.
«Починщик» в вашм примере — балласт, который на хер никому не нужен. Именно они создают бесполезные митинги и бесконечные потоки е-мейлов.
Продакт-менеджер — это такой же узкий специалист как дизайнер или программист, он не управленец, если только ему специально не дали управление командой работающей над его продуктом, поэтому сравнивать их не совсем корректно.
Когда вы поработаете на проекте, состоящем из 20 и более человек (из нескольких разных команд), причем поработаете без проджект менеджера, тогда и поговорим. Я понимаю, что трудно понять суть ценности управленца в ситуации, когда работаешь в маленькой команде, прекрасно справляющейся с самоорганизацией самостоятельно, и где присутствие плохого менеджера только усугубляет проблемы.
Когда вы поработаете на проекте, состоящем из 20 и более человек (из нескольких разных команд), причем поработаете без проджект менеджера, тогда и поговорим. Я понимаю, что трудно понять суть ценности управленца в ситуации, когда работаешь в маленькой команде, прекрасно справляющейся с самоорганизацией самостоятельно, и где присутствие плохого менеджера только усугубляет проблемы.
Да я вас умоляю!
У меня сегодня часовой митинг, организованный менеджером, о том как идут дела в проекте. Час! Целый час я буду слушать всякую фигню, которую за две минуты можно получить из Jira. Причем, даже если все и решится за 30 минут, остальные 30 будет пустая болтовня на абсолютно отвлеченные темы, не относящиеся к работе — как же, ведь запланирован час!
У нас 4 разработчика в Сиэтле, 2 в Калифорнии и менеджер, которая 8 часов в день должна спрашивать нас как идут дела, раскрашивать квадратики в графиках и рапортовать CEO.
Да пошли вы на хер, такие менеджеры! Если тебе нужна инфа — открой Jira и посмотри. Если у меня будут проблемы — я либо сам решу их в команде, либо сразу пойду к своему начальнику, поскольку только он может распоряжаться ресурсами.
Читая эти посты «недели менеджемента» на Хабре, прослеживается четкое желание авторов оправдать свое существование — и как без них нельзя, и какая сложная это наука/специальность — менеджер. На самом же деле — только от продакт менеджеров реальная польза.
К слову сказать, лет 5 назад я сам раздумывал о пути менеджера, даже на пробные MBA классы сходил. А потом посмотрел внимательнее, подумал, и решил — на фиг, на фиг.
У меня сегодня часовой митинг, организованный менеджером, о том как идут дела в проекте. Час! Целый час я буду слушать всякую фигню, которую за две минуты можно получить из Jira. Причем, даже если все и решится за 30 минут, остальные 30 будет пустая болтовня на абсолютно отвлеченные темы, не относящиеся к работе — как же, ведь запланирован час!
У нас 4 разработчика в Сиэтле, 2 в Калифорнии и менеджер, которая 8 часов в день должна спрашивать нас как идут дела, раскрашивать квадратики в графиках и рапортовать CEO.
Да пошли вы на хер, такие менеджеры! Если тебе нужна инфа — открой Jira и посмотри. Если у меня будут проблемы — я либо сам решу их в команде, либо сразу пойду к своему начальнику, поскольку только он может распоряжаться ресурсами.
Читая эти посты «недели менеджемента» на Хабре, прослеживается четкое желание авторов оправдать свое существование — и как без них нельзя, и какая сложная это наука/специальность — менеджер. На самом же деле — только от продакт менеджеров реальная польза.
К слову сказать, лет 5 назад я сам раздумывал о пути менеджера, даже на пробные MBA классы сходил. А потом посмотрел внимательнее, подумал, и решил — на фиг, на фиг.
Слушайте, я вам могу с десяток примеров плохого разработчика привести, но разве это как-то доказывает ненужность разработчиков в принципе? «От них одни баги»? :)
По-хорошему, у вашего менеджера должно быть еще 4 таких же команды, и 8 часов на вас одних она тратить не должна. 15 минут в день на статус репорт, и затем еще сколько-то времени, если вы жалуетесь на какие-то проблемы, которые она должна разрулить (если это сэкономит вам время). Если у вас все хорошо, то и взаимодействие минимальное. И да, нормальный менеджер (я даже не говорю хороший) сам должен знать какие баги в Jira имеют отношение к его проекту, их статус и т.д.
По-хорошему, у вашего менеджера должно быть еще 4 таких же команды, и 8 часов на вас одних она тратить не должна. 15 минут в день на статус репорт, и затем еще сколько-то времени, если вы жалуетесь на какие-то проблемы, которые она должна разрулить (если это сэкономит вам время). Если у вас все хорошо, то и взаимодействие минимальное. И да, нормальный менеджер (я даже не говорю хороший) сам должен знать какие баги в Jira имеют отношение к его проекту, их статус и т.д.
Хе-хе :) с разработчиками-то как раз все просто — плохих сразу видно и их увольняют. У менеджеров же способность мимикрировать :)
Вы меня извините за грубость, это я не вас имел в виду, а эту нашу бездельницу.
Вы меня извините за грубость, это я не вас имел в виду, а эту нашу бездельницу.
Да я прекрасно понимаю как может наболеть, у меня был когда-то бестолковый начальник, который славился умением набирать еще более бестолковых проджект-менеджеров. Это был тот самый случай, когда менеджер только мешал: он вклинивался между прекрасно коммуницирующих друг с другом специалистами, получал от них информацию, и передавал далее искаженно, создавая эффект испорченного телефона. В результате возникали конфликты, недопонимание, и закончилось все молчаливым бойкотом: ему просто перестали что-либо сообщать. «Как проект?» — «Хорошо». «Над чем работаете?» — «Над проектом». О каких-либо проблемах ставили перед фактом уже после их разрешения.
Но уволили по итогам и начальника, и нанятого им проджект менеджера. Мимикрировать можно долго, но не постоянно :)
Но уволили по итогам и начальника, и нанятого им проджект менеджера. Мимикрировать можно долго, но не постоянно :)
Вы не совсем справедливы.
Мне одно время было крайне тяжело заставить сотрудников актуальный и нормально оформленный статус в Jira выставлять. В итоге я, скажем, назначил всем отчитаться в 5 вечера (с запасом), в 6:30 статус спрашивают уже с меня. В результате долгое время я приходил к каждому и чуть ли не в буквальном смысле пинал людей, чтобы они логгировали работу.
Если бы все были предельно адекватны, умели думать об остальных и на пользу всей команды, вот тогда, возможно, и не пришлось бы вам так часто взаимодействовать с менеджерами.
Но мир не идеален.
Мне одно время было крайне тяжело заставить сотрудников актуальный и нормально оформленный статус в Jira выставлять. В итоге я, скажем, назначил всем отчитаться в 5 вечера (с запасом), в 6:30 статус спрашивают уже с меня. В результате долгое время я приходил к каждому и чуть ли не в буквальном смысле пинал людей, чтобы они логгировали работу.
Если бы все были предельно адекватны, умели думать об остальных и на пользу всей команды, вот тогда, возможно, и не пришлось бы вам так часто взаимодействовать с менеджерами.
Но мир не идеален.
Зачем быть управленцем? Эта такая же работа. Становитесь предпринимателями! Здесь нет предела твоему карьерному росту! Если ты предприниматель — ты можешь управлять, можешь продавать или можешь разрабатывать или в конце концов ты всегда можешь быть просто владельцем компании.
Это большие личные риски, как минимум. А просто (со)владелец компании, не управляющий ею, это скорее инвестор, чем предприниматель. Ещё важны масштабы для некоторых.
А вообще есть у меня мечта, поработать обычным программистом в компании, где у меня хотя бы блокирующий пакет. Но что-то мне подсказывает, что в плане бизнес-эффективности такая компания не будет считаться успешной, велика вероятность возникновения паразитных обратных связей., затрагивающих не только прямую «вертикаль власти», но и всю иерархию управления. Подобные эффекты зачастую наблюдается в компаниях где есть «блатные» сотрудники, но тут, думаю, эффект будет ещё сильнее.
А вообще есть у меня мечта, поработать обычным программистом в компании, где у меня хотя бы блокирующий пакет. Но что-то мне подсказывает, что в плане бизнес-эффективности такая компания не будет считаться успешной, велика вероятность возникновения паразитных обратных связей., затрагивающих не только прямую «вертикаль власти», но и всю иерархию управления. Подобные эффекты зачастую наблюдается в компаниях где есть «блатные» сотрудники, но тут, думаю, эффект будет ещё сильнее.
Немного не в тему:
SPOT, KISS и тд— вторую аббревиатуру знаю, а про первую мне гугль ничего вменяемого не сказал, расшифруйте, пожалуйста.
1. Масштабируемость
Например, я сейчас занимаюсь написанием системы для анализа Big Data. Эта система используется нашими клиентами, API используется другими программистами. Некоторые части системы написаны другими, но у нас нет менеджера — мы справляемся сами.
2. Неустареваемость
Вы за 7 лет сменили 3 языка, я за 10 лет как писал, так и пишу на Java. И, судя по всему, еще буду писать ближайшие лет 10.
3. Интересность сложных задач
О да!!! Я раньше тоже возмущался быдлокодерскими задачами, но теперь я работаю в Reserh & Development отделе, и занимаюсь тем, что умею лучше всего — решаю сложные задачи.
4. Бесконечность развития проекта
Любой программист знает — проект можно развивать бесконечно.
5. Риски и ответственность
Зависит от проекта и от команды.
Например, я сейчас занимаюсь написанием системы для анализа Big Data. Эта система используется нашими клиентами, API используется другими программистами. Некоторые части системы написаны другими, но у нас нет менеджера — мы справляемся сами.
2. Неустареваемость
Вы за 7 лет сменили 3 языка, я за 10 лет как писал, так и пишу на Java. И, судя по всему, еще буду писать ближайшие лет 10.
3. Интересность сложных задач
О да!!! Я раньше тоже возмущался быдлокодерскими задачами, но теперь я работаю в Reserh & Development отделе, и занимаюсь тем, что умею лучше всего — решаю сложные задачи.
4. Бесконечность развития проекта
Любой программист знает — проект можно развивать бесконечно.
5. Риски и ответственность
Зависит от проекта и от команды.
и Java, и .NET обладает рядом существенных недостатков (и технических, и организационных, связанных с разработкой на этих платформах и разработчиками).
пожалуй, по универсальности, скорости, уровню интеграции с железом напрямую и мощи я признаю один язык — чистый си. с++ еще можно добавить как улучшенную версию, мощь ООП и ряд других плюшек.
впрочем, в современном мире железом можно заткнуть даже тормозную и глюкавую платформу. и это дело вкуса, как говорится.
пожалуй, по универсальности, скорости, уровню интеграции с железом напрямую и мощи я признаю один язык — чистый си. с++ еще можно добавить как улучшенную версию, мощь ООП и ряд других плюшек.
впрочем, в современном мире железом можно заткнуть даже тормозную и глюкавую платформу. и это дело вкуса, как говорится.
Это зависит от задач.
Для C/C++ — своя ниша, для Java — своя, и они не особо пересекаются. Не могу ничего сказать про .NET, не в курсе.
В нишу C я не лезу, мне и своей хватает, и будет хватать еще долго.
Для C/C++ — своя ниша, для Java — своя, и они не особо пересекаются. Не могу ничего сказать про .NET, не в курсе.
В нишу C я не лезу, мне и своей хватает, и будет хватать еще долго.
IMHO разумеется.
Кого-то тошит от плюсов и он боготворит Джаву, или си шарп.
А так, любой язык под свои задачи. Офисную автоматизацию я писал на Дельфях, клиент-серверное приложение для управление роботом Кавасаки на с++, под веб — в зависимости от задач, ASP/.NET, потом был перл, питон, пхп.
Все это можно и на Джаве, и на сях написать с определенными усилиями, но зачем?
Кого-то тошит от плюсов и он боготворит Джаву, или си шарп.
А так, любой язык под свои задачи. Офисную автоматизацию я писал на Дельфях, клиент-серверное приложение для управление роботом Кавасаки на с++, под веб — в зависимости от задач, ASP/.NET, потом был перл, питон, пхп.
Все это можно и на Джаве, и на сях написать с определенными усилиями, но зачем?
Ну я в целом хотел выразить мысль, что описанные вами 5 причин — они не только для управленца, они в принципе для любой должности подходят. Исторически сложилось, что мужчина — исследователь, охотник, добытчик. Вот поэтому нам и нравится работа, чтобы была новизна, чтобы можно было решать сложные задачи, исследовать новое, развиваться. Ну и плюс власть, конечно :)
Sign up to leave a comment.
Пять причин быть управленцем