Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 203
Правдиво, ждём ответной статьи «Top 5 раздражающих моментов в работе менеджера» :)
Эх, а ExtJS то тут причем? Хороший фреймворк для понимающих разработчиков.
Ну я, может, привел неудачный пример. Это типа когда вам говорят, не понимая — а табличку обязательно с использованием Ruby напиши, я читал вчера, в стартапах инвесторам нравится этот Ruby. И плевать, что проект написан, к примеру, на сях или перле, и руби там рогами не уперся.
Но в целом статься норм,
Но в целом статься норм
ок
Deja vu на Яндекс.Панорамах
Бесит когда дают задачи, к которым я просто не готов, а потом еще и наезжают на сроки и качество, публично.
Под «не готов» имеются ввиду задачи, решения которых предполагает знания конкретных языков, технологий, библиотек — которые я не знаю. Притом без времени на изучение.
P. S. Не поймите меня неправильно, учить новые технологии и копаться в их нюансах — это хорошо, однозначно хорошо. Просто в моем случае, это было в убыток качеству и срокам, в следствии чего я стал главным негативным героем компании. Бесят.
P. P. S. Я все-же решил все задачи, которые мне дали, но закончилось это тем, что я был полностью демотивирован и нашел новую работу.
Под «не готов» имеются ввиду задачи, решения которых предполагает знания конкретных языков, технологий, библиотек — которые я не знаю. Притом без времени на изучение.
P. S. Не поймите меня неправильно, учить новые технологии и копаться в их нюансах — это хорошо, однозначно хорошо. Просто в моем случае, это было в убыток качеству и срокам, в следствии чего я стал главным негативным героем компании. Бесят.
P. P. S. Я все-же решил все задачи, которые мне дали, но закончилось это тем, что я был полностью демотивирован и нашел новую работу.
Я сам программист, но вот не вижу в описываемых ситуациях ничего ужасного. Надо понять, что — в нормальной команде — и Вы, и менеджер делаете одно общее дело. Просто смотрите на него с немного разных сторон.
1. Да, конечно, вопрос, заданный невовремя, выбивает из рабочего ритма. (Правда, умение быстро входить в рабочее состояние — это часть квалификаци...) И не очень важно, о чём это вопрос. С другой стороны, бывает и так, что ответ действительно нужен срочно.
А что касается вопроса «Сколько займёт сделать?» — так начальник, как правило, и не ожидает точного ответа. На всякий случай это нао дроговорить — и спокойно дать прикидку, с пояснениями. Примерно так: «Вася, сколько времени займёт сделать онлайн-магазин?» — «Ну, Пётр Петрович, в лучшем случае, если простенький и стандартный, то можем взять готовый и за неделю его настроим и раскрасим. Ну, а если что-то шибко навороченное да нестандартное, то надо будет самим писать. Примерно за месяцев 6-9 сделаем». Вполне возможно, что начальника интересовало, не займет ли это год, и Вашг ответ его полностью устроит. И все будут довольны.
2. Такие ситуации происходят, когда программисты не держат менеджера в курсе происходящего. Конечно, когда программист сказал «За неделю сделаем», а работает уже почти месяц, к нему возникают вопросы. Возможно, задержка произошла из-за того, что менеджер подкидывал много изменений — но программист виноват в том, что не предупредил его о задержке: «Пётр Петрович, если вы хотите добавить в магазин функционал блэкджека, мы это сделаем — но это удлинит срок на… дайте прикинуть… примерно четыре дня.» Если программист это сделал, ответственность перешла к мэнеджеру, и ругать тот может только себя. Ну и о всяких проблемах надо сообщать: «Пётр Петрович, мы, когда обещали локализовать продукт для Израиля, не учли, что иврит пишется в другую сторону. Будет задержка — надо переделать дизайн.» Неприятно, конечно, но мэнеджер в курсе происходящего и сможет принять меры к тому, чтобы никакой катастрофы не случилось.
3. Могу только повторить: да, отвлекать нехорошо, и если это вошло у мэнеджера в привычку, его надо от этого отучать. Но бывает и так, что нужно срочно. Ведь бывает, правда?
4. Рефакторинг, заявленный как отдельная деятельность, никогда не вызывает восторга у менеджеров. Причины к тому разные, например, связанные с бухгалтерией. Решение тут очень простое: закладывать рефакторинг в оценку времени. И, опять-таки, все будут довольны.
5. Тут, возможно, имеет место непонимание. Возможно, мэнеджер предполагает, что в Ваши обязанности входит и вёрстка. (А возможно, так оно и есть!). В остальных случавях нужно просто объяснить мэнеджеру, что у Вас вёрстка получится долго, дорого и хреново, и что дешевле найти верстальщика.
В общем, главное — не раздражаться, а пытаться понять друг друга.
1. Да, конечно, вопрос, заданный невовремя, выбивает из рабочего ритма. (Правда, умение быстро входить в рабочее состояние — это часть квалификаци...) И не очень важно, о чём это вопрос. С другой стороны, бывает и так, что ответ действительно нужен срочно.
А что касается вопроса «Сколько займёт сделать?» — так начальник, как правило, и не ожидает точного ответа. На всякий случай это нао дроговорить — и спокойно дать прикидку, с пояснениями. Примерно так: «Вася, сколько времени займёт сделать онлайн-магазин?» — «Ну, Пётр Петрович, в лучшем случае, если простенький и стандартный, то можем взять готовый и за неделю его настроим и раскрасим. Ну, а если что-то шибко навороченное да нестандартное, то надо будет самим писать. Примерно за месяцев 6-9 сделаем». Вполне возможно, что начальника интересовало, не займет ли это год, и Вашг ответ его полностью устроит. И все будут довольны.
2. Такие ситуации происходят, когда программисты не держат менеджера в курсе происходящего. Конечно, когда программист сказал «За неделю сделаем», а работает уже почти месяц, к нему возникают вопросы. Возможно, задержка произошла из-за того, что менеджер подкидывал много изменений — но программист виноват в том, что не предупредил его о задержке: «Пётр Петрович, если вы хотите добавить в магазин функционал блэкджека, мы это сделаем — но это удлинит срок на… дайте прикинуть… примерно четыре дня.» Если программист это сделал, ответственность перешла к мэнеджеру, и ругать тот может только себя. Ну и о всяких проблемах надо сообщать: «Пётр Петрович, мы, когда обещали локализовать продукт для Израиля, не учли, что иврит пишется в другую сторону. Будет задержка — надо переделать дизайн.» Неприятно, конечно, но мэнеджер в курсе происходящего и сможет принять меры к тому, чтобы никакой катастрофы не случилось.
3. Могу только повторить: да, отвлекать нехорошо, и если это вошло у мэнеджера в привычку, его надо от этого отучать. Но бывает и так, что нужно срочно. Ведь бывает, правда?
4. Рефакторинг, заявленный как отдельная деятельность, никогда не вызывает восторга у менеджеров. Причины к тому разные, например, связанные с бухгалтерией. Решение тут очень простое: закладывать рефакторинг в оценку времени. И, опять-таки, все будут довольны.
5. Тут, возможно, имеет место непонимание. Возможно, мэнеджер предполагает, что в Ваши обязанности входит и вёрстка. (А возможно, так оно и есть!). В остальных случавях нужно просто объяснить мэнеджеру, что у Вас вёрстка получится долго, дорого и хреново, и что дешевле найти верстальщика.
В общем, главное — не раздражаться, а пытаться понять друг друга.
Хороший менеджер должен быть осведомлен об этих нюансах. К примеру нужно внести какие-то новые фичи или изменения, то как правило следует вопрос, на сколько это может быть сложно и не поставит ли под угрозу сроки или на сколько это удленнит сроки. Если такие вещи программист должен объяснять менеджеру, то какой это блин менеджер на проекте?
Если менеджер адекватен — согласен, все решается.
Правда, в ваших словах часть задач менеджера смещена на программиста. Программист должен отучить менеджера от вредных привычек, или там пойти навстречу в плане срочности.
В общем, имхо, результат труда программиста кормит манеджера, и отвлекать днем должны быть ну очень срочные причины.
А так поддерживаю, все дело в коммуникациях и адекватности сторон. Но как редко это бывает!
Правда, в ваших словах часть задач менеджера смещена на программиста. Программист должен отучить менеджера от вредных привычек, или там пойти навстречу в плане срочности.
В общем, имхо, результат труда программиста кормит манеджера, и отвлекать днем должны быть ну очень срочные причины.
А так поддерживаю, все дело в коммуникациях и адекватности сторон. Но как редко это бывает!
>В общем, имхо, результат труда программиста кормит манеджера
Эта фраза как раз показывает, что вы не считаете, что делаете общее дело. Как-бы программист зарабатывает деньги, а менеджер как-бы эксплуатирует программиста в своих интересах.
Между тем, может быть совершенно противоположный взгляд на эти вещи. Кормит программиста заказчик, который покупает продукт. И менеджер, который удовлетворяет потребности заказчика.
Поэтому нужно прежде всего понять, оба работают на одно дело, тогда вопрос кто кого кормит сам сабой отпадет как не нужный.
Эта фраза как раз показывает, что вы не считаете, что делаете общее дело. Как-бы программист зарабатывает деньги, а менеджер как-бы эксплуатирует программиста в своих интересах.
Между тем, может быть совершенно противоположный взгляд на эти вещи. Кормит программиста заказчик, который покупает продукт. И менеджер, который удовлетворяет потребности заказчика.
Поэтому нужно прежде всего понять, оба работают на одно дело, тогда вопрос кто кого кормит сам сабой отпадет как не нужный.
На моей практике просто очень хорошие менеджеры получаются из разработчиков с развитым социальным компонентом: люди с большим опытом разработки, которые смещаются в менеджмент. С такими людьми всех этих проблем просто не возникает. Другой вопрос, что людей у которых хорошо развита и «техническая» и «гуманитарная» составляющая довольно мало.
Как дополнение к п.2.
Работаю сейчас напрямую с чехами и немцами — отношение к случившимся факапам у них следующее — да, ты ошибся, бывает, случается. Но сообщи об этом вовремя!
Работаю сейчас напрямую с чехами и немцами — отношение к случившимся факапам у них следующее — да, ты ошибся, бывает, случается. Но сообщи об этом вовремя!
Ну да, я работаю в Штатах — здесь тоже как правило такой подход. (Хотя бывают и уроды, как и везде...)
Одно время работали с компанией-заказчиком, которая уже давно работает с софтом и отлично понимает все тонкости программирования. Сроки там не настолько важны, просто ты получишь те же деньги за срок больший, чем оговаривалось вначале.
Согласен, прежде чем валить всё на менеджера, стоит обратить внимание насколько ты сам понимаешь и чувствуешь границы своих обязанностей и компетенции. Если с этим всё в порядке, то ты без истерик сообщишь об их нарушении менеджеру, чем и избавишь себя от решения не своих задач и нереальных сроков — конечно, это приходит с опытом.
Лучший комментарий
1. А сколько займет сделать этот раздел (дается ТЗ из одной строки)?
Поздравляю, перед вами типичный финансовый менеджер, которого поставили на место производственного, и он не тянет.
Мой ответ был бы: «От двух минут до двух месяцев. Разброс большой, потому что задание абстрактно, я не могу дать точный ответ»
2. Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя! (моют мозг по сроку из пункта 1)
Любишь перекладывать ответственность? Люби и противодействие таким замашкам. Прошу прощения, я давал ориентирочные сроки, а не конечные. В следующий раз буду точнее (x2..x5 ориентировочный срок выполнения)
3. Глянь срочно, тут надо за час сделать табличку! (кидается ссылка на чужой код)
Можно до точки дописать? Прошло три часа… Глядишь, и задача уже не такая срочная, и важность ее не такая важная…
4. Никакого рефакторинга, мне это нужно сегодня!
А когда мне выделят время на рефакторинг? А можно в письменном виде…
5. Сверстай по-быстрому это, пожалуйста, и лучше на extJS.
Без проблем, мне на изучение технологии нужно порядка двух месяцев. После этого я сверстаю. Я пошел за книжками, надеюсь мне оплатят их стоимость?
При таком противодействии с человеком не хочется работать. Если я спрашиваю про сроки, я не ожидаю точного ответа, но завышение в пять раз я увижу. Если я говорю, что что-то нужно срочно, работник попросил «дописать до точки» и исчез на три часа, я поручу это дело другому работнику, более ответственному и адекватному, и задумаюсь о том, имеет ли смысл продолжать наше сотрудничество. А учитывая ещё и хамский неконструктивный тон остальных диалогов — мне кажется, ответ на этот вопрос становится очевидным.
Почему же «неконструктивные»? Вот пример из личного опыта. Для поддержки виртуальной экономики в игре, над которой я работал, использовались услуги некоей компании… ну, назовём её «Альфа». В какой-то момент ко мне подошёл менеджер и спросил: «Слушай, а сколько времени займёт написать свою версию этой Альфы?» (Как я понимаю, это и есть то самое «ТЗ из одной строки»). Я ответил на это, что, естественно, точно сказать трудно, но если речь идёт только о нужно нам функционале, то мы сможем воспроизвести его за 3-5 месяцев. Менеджер был вполне удовлетворён и ушёл дальше по свои менеджерским делам.
Был ли этот вопрос конструктивен? С его точки зрения — да, и весьма. Он пришёл с совещания, на котором обсуждался вопрос о том, как можно снизить затраты. «Альфа» за свои услуги брала с нас немаленькие деньги. Получив мой ответ, менеджер смог примерно прикинуть, окупится ли отказ от услуг «Альфы» и имеет ли смысл этим заниматься.
Был ли этот вопрос конструктивен? С его точки зрения — да, и весьма. Он пришёл с совещания, на котором обсуждался вопрос о том, как можно снизить затраты. «Альфа» за свои услуги брала с нас немаленькие деньги. Получив мой ответ, менеджер смог примерно прикинуть, окупится ли отказ от услуг «Альфы» и имеет ли смысл этим заниматься.
Ну вот хорошо, давайте возьмем этот вопрос для примера. Вы ведь уже начали давать на него вполне конструктивный ответ. Примитивный многопользовательский блог с более-менее стандартным дизайном потребует несколько дней. На полное воспроизведение функционала Хабра в нынешнем виде уйдёт… ну, давайте скажем, полгода работы двух программистов и дизайнера. Понятно, что время на построение коммьюнити (которая и есть Хабр!) мы не учитываем — тут я не специалист.
Мы получили вполне конструктивный ответ. Всем понятно, что ответ примерный, и на этом уровне точности полгода могут превратиться и в 8 месяцев — а могут оказаться и четырьмя. Но это заведомо не два года и не месяц. Насколько конструктивный был вопрос — судить трудно, но я вполне вижу кучу вариантов. Ну, например, на горизонте нарисовался инвестор, который хочет вложить деньги как раз во что-нибудь такого типа :)
Мы получили вполне конструктивный ответ. Всем понятно, что ответ примерный, и на этом уровне точности полгода могут превратиться и в 8 месяцев — а могут оказаться и четырьмя. Но это заведомо не два года и не месяц. Насколько конструктивный был вопрос — судить трудно, но я вполне вижу кучу вариантов. Ну, например, на горизонте нарисовался инвестор, который хочет вложить деньги как раз во что-нибудь такого типа :)
Когда я даю такой ответ, то чётко предупреждаю: это — прикидка, предварительная оценка, estimate — или даже guesstimate. Да, бывают неадекватные менеджеры, которые не понимают, что такое «прикидка». Бывает также, что прикидка каким-то образом просачивается наверх, по пути загадочным образом превращаясь в точный срок. Но мне такие случаи практически не встречались. Гораздо чаще встречались программисты, которые не понимают, когда их просят сделать прикидку и сами не чувствуют разницы между прикидкой и планом. Они или абсолютно уверенно называют срок, или впадают в ступор и не могут ничего сказать даже приблизительно.
При таком противодействии с человеком не хочется работать.
При таком управлении — тоже. Это не управление, это перекладывание ответственности, полное отсутствие понимания оценки эффективности работника, менеджмент-импотенция так сказать. Задача программиста — писать код. Задача менеджера — сделать так, чтобы программист всегда знал, сколько ему кода нужно еще написать, когда, в какой срок. Другими словами — подносить патроны.
Идеально, если перед работником стоит только одна задача в один момент времени. Вот это для меня вершина управления. Все работают, всё предсказуемо, все прекрасно оценивается и прогнозируется. Никаких цейтнотов, дедлайнов, бесконечных прокрастинаций, и прочего негатива.
>Идеально, если перед работником стоит только одна задача в один момент времени
Круто! Найдете такую фирму, скиньте мне контакты, плиз!
> Все работают, всё предсказуемо, все прекрасно оценивается и прогнозируется
Наконец-то в IT можно нормально прогнозировать сроки! Подскажите, пожалуйста, для этого нужны всего-навсего идеальные сотрудники?
Круто! Найдете такую фирму, скиньте мне контакты, плиз!
> Все работают, всё предсказуемо, все прекрасно оценивается и прогнозируется
Наконец-то в IT можно нормально прогнозировать сроки! Подскажите, пожалуйста, для этого нужны всего-навсего идеальные сотрудники?
На практике п.1 вываливается в:
— Я уже клиенту пообещала выслать в обед смету!!!
если не прикинешь сроки, то «галочку» поставит — «не профи»
Выходит, что некто, кто не может оценить сроки, но быстро отвечает, выглядит в глазах аккаунта/менеджера более профессиональным, чем тот кто просит ТЗ полное.
— Я уже клиенту пообещала выслать в обед смету!!!
если не прикинешь сроки, то «галочку» поставит — «не профи»
Выходит, что некто, кто не может оценить сроки, но быстро отвечает, выглядит в глазах аккаунта/менеджера более профессиональным, чем тот кто просит ТЗ полное.
— Я уже клиенту пообещала выслать в обед смету!!!
— Ну так выполняй, раз обещал. Это не мои проблемы, что кто-то неверно оценивает сроки и риски
Если для кого-то выполнение формальностей или танец с бубнами является более приоритетным, чем процесс зарабатывания денег, то надо бежать от такого управления как можно дальше.
— Ну так выполняй, раз обещал. Это не мои проблемы, что кто-то неверно оценивает сроки и риски
Если для кого-то выполнение формальностей или танец с бубнами является более приоритетным, чем процесс зарабатывания денег, то надо бежать от такого управления как можно дальше.
Проблема в том, что ответ такой повлечет нытье или служебки начальству, что «диджитал» не считает смету. А если агентство крупное, то велик шанс что начальство не разбирается в тонкостях и начнутся нервотрепки «какого фига?». В конечном итоге аккаунт оказывается дебилом/дебилкой, но так как клиент превыше всего, то вечером пара человек сидят и думают как бы не прогодать с ценой и сроками, так как на разборки ушло время и клиент уже мирно спит дома.
На такие служебки и нервотрепки нужно отвечать одной фразой — это не моя зона ответственности. Я не брал и не хочу брать на себя ответственность за неправильную оценку сроков, поэтому прошу избавить меня от спасения чьей-то задницы после того, как она облажалась. Расстановка приоритетов и сроков — задача управления, а не разработки.
Я все же за то, что бы развернутый план работ по проекту спускался «вниз» и непосредственные исполнители прописывали сроки каждого этапа.
Конкретно у меня это еще и в виде «аукциона», где по каждой задаче каждый пишет «я сделаю за ХХ часов» (кто хочет сделать задачу). в конечном итоге ПО распределяет задачи по людям с минимальными сроками (грубо говоря, ибо есть еще около 3 показателей работы, которые влияют на выбор).
Есть еще момент. Если человек обещал сделать нечто за время Х, то с бОльшей вероятностью он выдержит сроки, а не сольет их со словами «это не я оценивал, кто вам сказал, что это реально сделать за срок ХХ»
Конкретно у меня это еще и в виде «аукциона», где по каждой задаче каждый пишет «я сделаю за ХХ часов» (кто хочет сделать задачу). в конечном итоге ПО распределяет задачи по людям с минимальными сроками (грубо говоря, ибо есть еще около 3 показателей работы, которые влияют на выбор).
Есть еще момент. Если человек обещал сделать нечто за время Х, то с бОльшей вероятностью он выдержит сроки, а не сольет их со словами «это не я оценивал, кто вам сказал, что это реально сделать за срок ХХ»
Я все же за то, что бы развернутый план работ по проекту спускался «вниз» и непосредственные исполнители прописывали сроки каждого этапа.
Таким образом вы на исполнителей перекладываете ответственность за нарушение этих самых сроков.
Смотрите, давайте еще раз пройдемся по акцентам. Есть два типа мышления работников: «я боюсь, что меня поставят в жесткие рамки, поэтому я не хочу, чтобы мне ставили сроки без моего ведома» (боязнь переработок) и «я не доверяю своему менеджеру в плане оценки сроков» (боязнь ответственности). Но это мышление возникает только в том случае, если есть негативные моменты в работе, а именно — менеджмент не умеет управлять загрузкой подчиненных.
Менеджер же попадает в другую крайность. Когда он не может нормально оценить сроки выполнения работ своих подчиненных, его никто не освобождал от ответственности за срыв сроков. Чтобы хоть как-то увернуться от длани наказания, он инстинктивно перекладывает оценку сроков на работников.
Страхи работников и неумение менеджера дополняют друг друга, и они вместе попадают в ловушку, взаимно аннигилируя. Начинаются склоки, ругань, коллектив распадается, страдает — компания.
Когда менеджер снимает с работника ответственность за выполнение сроков, ему приходится
1. Искать пути оценки эффективности работника
2. Менять приоритеты задач, чтобы достичь поставленного результата
3. Учиться понимать сложность задач
4. Учиться стимулировать работников выполнять работу в срок
Работник будет учиться доверять менеджеру в плане оценок сроков, конфликтные ситуации сойдут на нет (главное, после пропесочивания, менеджер не должен срываться на работниках за невыполнение обязательств, а должен искать подходы и решения, как не допустить этого в дальнейшем)
В итоге все будут заниматься своей работой, а не склоками и разборками, кто кому злобный Буратино. Эффект будет позитивный для компании.
Если менеджер офигенский профи и бывший разраб + у него есть 48 часов в сутках, то ок.
Если менеджер получает ТЗ на 1800 страниц с комментариями заказчика «тут мы не все расписали, скоро допишем по остальным модулям», то перелопатить это чтиво за неделю — титанический друд ведущий к сумасшествию.
Давайте поделим «программистов» на Программистов и Кодеров.
Конечного кодера тимлид/ведущий разраб/ктулку отвечающий за задачу спрашивает: — на входе есть массив описанный на странице 657, нужна функция сортировки по полю Х. За сколько сделаешь?"
Один ответит: — ох, я эти сортировки пачками на завтрак жру, минут 20.
Второй ответит: а ХЗ, надо погуглить как лучше сделать.
Я же реализовал систему, когда не надо ходить между 100 программистами/кодерами (а много кто на удаленке) и по каждому пункту спрашивать.
Т.е. вместо того что бы 1 менеждер проекта/тимлид/Вася Пупкин сидели и считали месяца 2 сроки/цену, 100 разрабов/кодеров могут с достаточно точной степенью оценки ответить на общий вопрос.
Срок оценочный умножается на коэффициент «факапность в сроках» (вычисляется по прошлым работам) и «факапность в работе» (отчеты тестеров и т.п.) — получаем тот срок, что ближе к реальности.
Цель всего у меня достаточно простая: снизить требования к ПМ и его нагрузку и добиться хоть какой то ответственности от программистов/кодеров.
Если программист/кодер не несет ответственности за сроки (которые он сам же и назвал) и не уведомил вовремя о сложностях или ошибках в оценке, то… «давай досвидания» как только коэффициенты его упадут ниже пороговых.
Да, разрабы срут кирпичами от ответственности, особенно когда на проекте их мало, а проект большой с плотный график и факап одного — это головная боль всех.
Но мы и платим адекватам которые берут на себя часть ответственности.
Как мне кажется, если ПМ адекватен на 10000% и выставил сроки на задачу в 2 часа, а прогер делает её 10 и ноет про неверную оценку, то не всегда ПМ неправ. В моей системе я имею среднестатистическую оценку нескольких людей. Что, кстати, не значит, что тимлид/ПМ не выставят сроки больше, так как видят подводные камни.
Я просто сократил на порядок время оценки проекта, понизил страх потерять «бойца» в процессе работы, конкуренция внутри команда за скорость/деньги (оценка задачи в 5 часов* ставка за час = число денег заработанных за выполнение, если сделаешь быстрее, то и за месяц сделаешь больше задач = получаешь больше денег) — система саморегулируется получше, чем «карма» на ряде хаброподобных сайтах.
Если менеджер получает ТЗ на 1800 страниц с комментариями заказчика «тут мы не все расписали, скоро допишем по остальным модулям», то перелопатить это чтиво за неделю — титанический друд ведущий к сумасшествию.
Давайте поделим «программистов» на Программистов и Кодеров.
Конечного кодера тимлид/ведущий разраб/ктулку отвечающий за задачу спрашивает: — на входе есть массив описанный на странице 657, нужна функция сортировки по полю Х. За сколько сделаешь?"
Один ответит: — ох, я эти сортировки пачками на завтрак жру, минут 20.
Второй ответит: а ХЗ, надо погуглить как лучше сделать.
Я же реализовал систему, когда не надо ходить между 100 программистами/кодерами (а много кто на удаленке) и по каждому пункту спрашивать.
Т.е. вместо того что бы 1 менеждер проекта/тимлид/Вася Пупкин сидели и считали месяца 2 сроки/цену, 100 разрабов/кодеров могут с достаточно точной степенью оценки ответить на общий вопрос.
Срок оценочный умножается на коэффициент «факапность в сроках» (вычисляется по прошлым работам) и «факапность в работе» (отчеты тестеров и т.п.) — получаем тот срок, что ближе к реальности.
Цель всего у меня достаточно простая: снизить требования к ПМ и его нагрузку и добиться хоть какой то ответственности от программистов/кодеров.
Если программист/кодер не несет ответственности за сроки (которые он сам же и назвал) и не уведомил вовремя о сложностях или ошибках в оценке, то… «давай досвидания» как только коэффициенты его упадут ниже пороговых.
Да, разрабы срут кирпичами от ответственности, особенно когда на проекте их мало, а проект большой с плотный график и факап одного — это головная боль всех.
Но мы и платим адекватам которые берут на себя часть ответственности.
Как мне кажется, если ПМ адекватен на 10000% и выставил сроки на задачу в 2 часа, а прогер делает её 10 и ноет про неверную оценку, то не всегда ПМ неправ. В моей системе я имею среднестатистическую оценку нескольких людей. Что, кстати, не значит, что тимлид/ПМ не выставят сроки больше, так как видят подводные камни.
Я просто сократил на порядок время оценки проекта, понизил страх потерять «бойца» в процессе работы, конкуренция внутри команда за скорость/деньги (оценка задачи в 5 часов* ставка за час = число денег заработанных за выполнение, если сделаешь быстрее, то и за месяц сделаешь больше задач = получаешь больше денег) — система саморегулируется получше, чем «карма» на ряде хаброподобных сайтах.
Если менеджер офигенский профи и бывший разраб + у него есть 48 часов в сутках, то ок.
Ну мы же говорим только о производственном менеджере. Он просто обязан знать матчасть. Без вариантов.
… конкуренция внутри команда за скорость/деньги...
У вас нет команды, так как они конкурируют между собой
Команда и конкуренция личная(профессионализм) — это не противостояние.
Конкуренция есть в профессионализме.
Опять же, есть 100 задач в системе и даже если из 100 программистов найдется некто, кто поставит минимальное время выполнения, то это не значит что он все получит «в одну харю». просто у него будет приоритет по выполнению более сложных и/или длительных работ (запас в сроке — это ок).
При распределении задач в команде Вы, наверняка, тоже пользуетесь некими показателями эффективности. Кто-то делает все медленно, кто-то долго раскачивается, кто-то уже делал нечто подобное, кто-то постоянно переоценивает сроки, кто-то много ошибок делает и тестеры заворачивают.
Конкуренция есть в профессионализме.
Опять же, есть 100 задач в системе и даже если из 100 программистов найдется некто, кто поставит минимальное время выполнения, то это не значит что он все получит «в одну харю». просто у него будет приоритет по выполнению более сложных и/или длительных работ (запас в сроке — это ок).
При распределении задач в команде Вы, наверняка, тоже пользуетесь некими показателями эффективности. Кто-то делает все медленно, кто-то долго раскачивается, кто-то уже делал нечто подобное, кто-то постоянно переоценивает сроки, кто-то много ошибок делает и тестеры заворачивают.
В большинстве своем нытье.
Чем больше опыт программиста, тем быстрее и успешнее он рассчитывает сроки.
Ну ты же действительно назвал какие-то конечные сроки, которые превысил.
Давать фидбек по срокам важнейшая задача любого исполнителя.
Ситуация не нормальная, но такое иногда и правда необходимо сделать срочно.
Вспомните, наверняка вы тоже обращались к менеджерам и руководству со срочными вопросами.
Опытный программист занимается теневым рефакторингом и во время задачи.
Кто верстает должно решаться отдельно и заранее.
Однако, если вы уже верстали в компании, то, скорее всего, и будете продолжать это делать.
Это надо пресекать, да.
По одному предложению нельзя смоделировать приложение
Чем больше опыт программиста, тем быстрее и успешнее он рассчитывает сроки.
Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя
Ну ты же действительно назвал какие-то конечные сроки, которые превысил.
Давать фидбек по срокам важнейшая задача любого исполнителя.
Глянь срочно, тут надо за час сделать табличку
Ситуация не нормальная, но такое иногда и правда необходимо сделать срочно.
Вспомните, наверняка вы тоже обращались к менеджерам и руководству со срочными вопросами.
Никакого рефакторинга, мне это нужно сегодня
Опытный программист занимается теневым рефакторингом и во время задачи.
Сверстай по-быстрому это, пожалуйста
Кто верстает должно решаться отдельно и заранее.
Однако, если вы уже верстали в компании, то, скорее всего, и будете продолжать это делать.
и лучше на extJS
Это надо пресекать, да.
Программист, вообще-то, не должен рассчитывать сроки. Это не его зона ответственности.
Программист должен оценивать сроки. Это его прямая обязанность. Рассчитает всё проджект мэнеджер.
Если вы даете программисту оценивать сроки, значит у вас серьезная проблема с оценкой эффективности их работы. Ее попросту у вас нет. Нормальный производственный менеджер, у которого на руках есть хотя бы статистика потребления бюджетов времени, может с легкостью спрогнозировать временные затраты будущих проектов. И они, что самое смешное, будут гораздо точнее, чем те, которые выдадут программисты. Мало того, нельзя спрашивать заинтересованную сторону.
Работник должен работать, а не балансировать между двух огней. Он должен знать, какой бюджет по времени отведен на какую-то из задач и постараться уложиться в эти рамки. Если бюджет нереальный — это не его проблема, а менеджера, который выделил такой бюджет.
Я понимаю, что многие попадали в ситуацию, что кто-то там наобещал, а нам выполнять. Ну так это не вы наобещали, почему вы должны спасать кому-то задницу? Это его проблемы.
Отсутствие адекватного менеджмента — это проблема многих компаний. Отсутствие понимания зон ответственности — еще большая проблема.
Работник должен работать, а не балансировать между двух огней. Он должен знать, какой бюджет по времени отведен на какую-то из задач и постараться уложиться в эти рамки. Если бюджет нереальный — это не его проблема, а менеджера, который выделил такой бюджет.
Я понимаю, что многие попадали в ситуацию, что кто-то там наобещал, а нам выполнять. Ну так это не вы наобещали, почему вы должны спасать кому-то задницу? Это его проблемы.
Отсутствие адекватного менеджмента — это проблема многих компаний. Отсутствие понимания зон ответственности — еще большая проблема.
Менеджер, исходя из опыта, статистики и т. п. может примерно оценить время на разработку всего проекта. («Интернет-магазин? Да, моя команда уже сделала три магазина. Думаю, что мы уложимся в два с половиной месяца....») Однако точно он не сможет сказать, пока не поговорит с командой.
Дело же не в оценке эффективности работы, а в оценке сложности задачи. А кто с этим справится лучше, чем опытный исполнитель? (Да, младшим сотрудникам доверять самостоятельную оценку нельзя.)
Дело же не в оценке эффективности работы, а в оценке сложности задачи. А кто с этим справится лучше, чем опытный исполнитель? (Да, младшим сотрудникам доверять самостоятельную оценку нельзя.)
Если ваш производственный менеджер не может вам сказать сроки, то гоните его в шею, перед вами менеджер не того типа.
Давайте приведу пример из строительства. Кого вы спрашиваете срок выполнения ремонта, работников, или прораба? Я бы никогда не спрашивал у работников, только у прораба. А почему? Потому что только он несет ответственность за выполнение обязательств. И как он будет организовывать работу своих подчиненных — мало кому интересно.
Удивительно, как люди негативно воспринимают идею снятия ответственности с работников по установке сроков. Задумайтесь хоть раз, какие выгоды сулит мой вариант развития событий, прежде чем минусы топтать. Я понимаю, что мое высказывание ломает все ваши стереотипы, но не стоит отбрасывать это как глупость из-за своих страхов.
Давайте приведу пример из строительства. Кого вы спрашиваете срок выполнения ремонта, работников, или прораба? Я бы никогда не спрашивал у работников, только у прораба. А почему? Потому что только он несет ответственность за выполнение обязательств. И как он будет организовывать работу своих подчиненных — мало кому интересно.
Удивительно, как люди негативно воспринимают идею снятия ответственности с работников по установке сроков. Задумайтесь хоть раз, какие выгоды сулит мой вариант развития событий, прежде чем минусы топтать. Я понимаю, что мое высказывание ломает все ваши стереотипы, но не стоит отбрасывать это как глупость из-за своих страхов.
Давайте не будем приводить примеры из строительства? Думать о команде программистов как о бригаде строителей — это заблуждение. Неспроста работу программиста часто сравнивают с работой художника.
А менеджер-бригадир, который лучше команды знает, как что делать и сколько времени это займет — прямой путь к срывам сроков.
А менеджер-бригадир, который лучше команды знает, как что делать и сколько времени это займет — прямой путь к срывам сроков.
Вот тут не совсем вы правы, можно сравнивать, потому что объектов одинаковых, как и программных продуктов — не бывает.
Один человек, топ-менеджер в крупной ИТ-компании, говорил: «я думал, что самые страшные раздолбаи встречаются среди программистов, но потом я начал работать со строителями» )
Один человек, топ-менеджер в крупной ИТ-компании, говорил: «я думал, что самые страшные раздолбаи встречаются среди программистов, но потом я начал работать со строителями» )
Это не заблуждение, это разная точка зрения.
Программисту платят не за яркость красок, не за буйство фантазии, не за красивый и качественный код. Ему платят за… создание практической (коммерческой) ценности. А если быть точнее, платят за время, которое он тратит на создание этой ценности. Результат работы программиста — программный продукт или его часть. Результат работы строителя — ремонт или его часть.
Приведу снова же пример из строительства. Ремонт делается по каким-то правилам, операции выполняются в определенной последовательности, иногда параллельно, иногда последовательно. Каждый работник знает объем работ, видит их сложность, и может, на основании предыдущего опыта, сказать свой прогноз бюджета времени. Однако это бюджет чистого времени, без форсмажоров, без простоев, без учета других работников. Если сложить прогнозы всех работников, получим далекий от реальности бюджет времени. Кто видит всю картину целиком, и может составить более реальный план работ? Бригадир. Мало того, бригадир аккумулирует опыт и проблематику всех работников разом, потому что работники выполняют задачи, а бригадир выполняет план работ (на один уровень абстракции выше). Теперь вопрос, если бригадир работает с одной командой и знает возможности и проблемы всех рабочих, он может на пятый раз дать свой прогноз, не спрашивая подчиненных? Думаю, легко. Будет ли его прогноз катастрофически неточным? Скорее всего нет, только потому, что ему банально для анализа больше данных доступно.
Еще нюанс, бригадир занимается еще и закупками материалов, и отсутствие расходных средств в наличии может растянуть время реализации с прогнозированной работником недели работы до двух месяцев. Теперь кто реальнее сроки назовет? Очевидно, бригадир.
Теперь проводим аналогии с программированием, заменяем «бригадир» на «менеджер», «ремонт» на «создание программного продукта»…
С точки зрения прикладных вещей, конечно же строительство и программирование разные вещи, но с точки зрения экономики и управления между ними нет особой разницы.
Программисту платят не за яркость красок, не за буйство фантазии, не за красивый и качественный код. Ему платят за… создание практической (коммерческой) ценности. А если быть точнее, платят за время, которое он тратит на создание этой ценности. Результат работы программиста — программный продукт или его часть. Результат работы строителя — ремонт или его часть.
Приведу снова же пример из строительства. Ремонт делается по каким-то правилам, операции выполняются в определенной последовательности, иногда параллельно, иногда последовательно. Каждый работник знает объем работ, видит их сложность, и может, на основании предыдущего опыта, сказать свой прогноз бюджета времени. Однако это бюджет чистого времени, без форсмажоров, без простоев, без учета других работников. Если сложить прогнозы всех работников, получим далекий от реальности бюджет времени. Кто видит всю картину целиком, и может составить более реальный план работ? Бригадир. Мало того, бригадир аккумулирует опыт и проблематику всех работников разом, потому что работники выполняют задачи, а бригадир выполняет план работ (на один уровень абстракции выше). Теперь вопрос, если бригадир работает с одной командой и знает возможности и проблемы всех рабочих, он может на пятый раз дать свой прогноз, не спрашивая подчиненных? Думаю, легко. Будет ли его прогноз катастрофически неточным? Скорее всего нет, только потому, что ему банально для анализа больше данных доступно.
Еще нюанс, бригадир занимается еще и закупками материалов, и отсутствие расходных средств в наличии может растянуть время реализации с прогнозированной работником недели работы до двух месяцев. Теперь кто реальнее сроки назовет? Очевидно, бригадир.
Теперь проводим аналогии с программированием, заменяем «бригадир» на «менеджер», «ремонт» на «создание программного продукта»…
С точки зрения прикладных вещей, конечно же строительство и программирование разные вещи, но с точки зрения экономики и управления между ними нет особой разницы.
Вообще-то заблуждение начинается в тот момент, когда работа программиста каждый раз разная, а работа строителя — каждый раз одинакова и оценена. Есть «расценки»:
— Метр обоев — 15 минут
— Метр кирпича — час
— Метр плитки — 3 часа
В программировании каждая задача уникальна, потому менеджер сначала спрашивает у исполнителей прикидки времени и зависимости для каждой детали, а потом делает из них сроки по проекту.
Полностью самостоятельно оценить продукт может только менеджер у обезьянок-программистов, которые делают раз у раз одинаковую работу, например — клепают шаблонные магазины, в каждый третий добавля.т комментарии, в каждый пятый — интеграцию с Хабром.
Мало мальски нестандартное задание. Например, игры, где каждая строка кода — произведение искусства может оценить только программист и то приблизительно.
— Метр обоев — 15 минут
— Метр кирпича — час
— Метр плитки — 3 часа
В программировании каждая задача уникальна, потому менеджер сначала спрашивает у исполнителей прикидки времени и зависимости для каждой детали, а потом делает из них сроки по проекту.
Полностью самостоятельно оценить продукт может только менеджер у обезьянок-программистов, которые делают раз у раз одинаковую работу, например — клепают шаблонные магазины, в каждый третий добавля.т комментарии, в каждый пятый — интеграцию с Хабром.
Мало мальски нестандартное задание. Например, игры, где каждая строка кода — произведение искусства может оценить только программист и то приблизительно.
Работа плиточника тоже каждый раз разная. Все объекты имеют уникальные особенности, начиная от конфигурации помещения, заканчивая особенностями применяемых технологий, инструментов, материалов. Каждая наклеенная полоска обоев имеет свои нюансы.
Я прекрасно понимаю, что чертовски обидно, когда работников мозга и клавиатуры сравнивают с работниками шпателя и мастерка, но речь идет не про важность и уникальность каждой профессии, а про управление.
Шикарный пример. С точки зрения бизнеса никому не интересно, будет эта строчка произведением искусства или говнокодом. Главное выполнение следующих условий: в срок за отведенное количество денег. И тут требования бизнеса (который обеспечивает программиста зарплатой, удобным креслом, печеньками и достойной оплатой труда) выполнять эти два условия не стимулируют слушать оценки конечных работников. Есть план работ, есть бюджеты времени, есть контроль выполнения, будьте добры выполнить требования бизнеса.
Я понимаю, что звучит это слишком резко и слишком агрессивно, и рука так и тянется заминусовать меня еще раз, и карму слить, но давайте реальнее смотреть на вещи.
Лично я не боюсь за своих работников называть сроки, и не боюсь ответственности за их срыв.
Я прекрасно понимаю, что чертовски обидно, когда работников мозга и клавиатуры сравнивают с работниками шпателя и мастерка, но речь идет не про важность и уникальность каждой профессии, а про управление.
Например, игры, где каждая строка кода — произведение искусства может оценить только программист и то приблизительно.
Шикарный пример. С точки зрения бизнеса никому не интересно, будет эта строчка произведением искусства или говнокодом. Главное выполнение следующих условий: в срок за отведенное количество денег. И тут требования бизнеса (который обеспечивает программиста зарплатой, удобным креслом, печеньками и достойной оплатой труда) выполнять эти два условия не стимулируют слушать оценки конечных работников. Есть план работ, есть бюджеты времени, есть контроль выполнения, будьте добры выполнить требования бизнеса.
Я понимаю, что звучит это слишком резко и слишком агрессивно, и рука так и тянется заминусовать меня еще раз, и карму слить, но давайте реальнее смотреть на вещи.
Лично я не боюсь за своих работников называть сроки, и не боюсь ответственности за их срыв.
При чём тут обида? Вы просто заблуждаетесь.
Скорее всего в силу слабого опыта. Возможно, у вас не было нестандартных проектов или вы не делали ничего действительно глобального.
Я сейчас работаю в одной из крупнейших гейм-дев фирм СНГ, за Wargaming.net такой сверхпопулярный проект как World of Tanks и огромное количество проектов в производстве.
У нас не применяется такой глупый подход, о котором вы рассказываете. Ни на одном проекте. Менеджер не делает оценку за программиста. Для этого есть лид программист в команде. Но даже лид в случае малой связанности с какой-то таской может передать задачу на эстимации рядовому программисту, который её будет выполнять.
Потому что в нестандартных проектах со сложными требованиями, а не в таких, как вы рассказываете, самую точную оценку может дать только человек, которых хорошо знает используемый стек технологий и особенности реализации определённого участка.
Скорее всего в силу слабого опыта. Возможно, у вас не было нестандартных проектов или вы не делали ничего действительно глобального.
Я сейчас работаю в одной из крупнейших гейм-дев фирм СНГ, за Wargaming.net такой сверхпопулярный проект как World of Tanks и огромное количество проектов в производстве.
У нас не применяется такой глупый подход, о котором вы рассказываете. Ни на одном проекте. Менеджер не делает оценку за программиста. Для этого есть лид программист в команде. Но даже лид в случае малой связанности с какой-то таской может передать задачу на эстимации рядовому программисту, который её будет выполнять.
Потому что в нестандартных проектах со сложными требованиями, а не в таких, как вы рассказываете, самую точную оценку может дать только человек, которых хорошо знает используемый стек технологий и особенности реализации определённого участка.
5 лет опыта управления разработкой SaaS'ов для банков, бюро кредитных историй, информационно-аналитических систем. Я просто заблуждаюсь…
То, что у вас не применяется такой подход, не значит, что он глупый. Это значит, что ваши менеджеры выполняют совершенно другую функциональную роль.
Сложность проектов не зависит от методики управления. Нет разницы, делать много мелких проектов или один большой и сложный. Везде есть одно и то же: за определенный срок нужно выполнить как можно больше работы. Максимизация прибыли, минимизация затрат. Одна из технологий минимизации затрат — перестать спрашивать заинтересованное лицо про время, которое он будет тратить на выполнение задачи, начать собирать статистику эффективности труда сотрудников и учить делать прогнозирование временных бюджетов менеджеров. Ведь программист хочет как можно меньше работать и как можно больше получать. :)
То, что у вас не применяется такой подход, не значит, что он глупый. Это значит, что ваши менеджеры выполняют совершенно другую функциональную роль.
Сложность проектов не зависит от методики управления. Нет разницы, делать много мелких проектов или один большой и сложный. Везде есть одно и то же: за определенный срок нужно выполнить как можно больше работы. Максимизация прибыли, минимизация затрат. Одна из технологий минимизации затрат — перестать спрашивать заинтересованное лицо про время, которое он будет тратить на выполнение задачи, начать собирать статистику эффективности труда сотрудников и учить делать прогнозирование временных бюджетов менеджеров. Ведь программист хочет как можно меньше работать и как можно больше получать. :)
Вот и получается, что менеджмент не доверяет программистам и использует их как наборщиков кода, нагрузив работой до предела, а программисты не заинтересованы в такой работе, и поэтому пытаются от нее ускользнуть, получив заодно побольше денег, раз удовольствия от работы никакого нет.
Не знаю, проблема ли это неадекватного менеджмента или плохого подбора кадров, но когда и там, и там все хорошо — программисты берут на себя ответственность за эффективность собственной работы и, соответственно, правильно оценивают задачи.
Не знаю, проблема ли это неадекватного менеджмента или плохого подбора кадров, но когда и там, и там все хорошо — программисты берут на себя ответственность за эффективность собственной работы и, соответственно, правильно оценивают задачи.
Хватит фантазировать. У меня все работают в очень хорошем темпе, без переработок (категорически запрещены), с нулевой текучкой кадров за 3 года. И причина кроется в том, что они просто работают, их никто не гонит в шею и не рассказывает про то, что он что-то обещал, а не выполнил. Из-за отсутствия давления дедлайнов, работы выполняется больше, и выполняется она лучше. Настроение в команде всегда отличное.
Мне вот интересно, почему вы хотите переложить на программистов ответственность за выполнение сроков? Вам кажется, что они без этого становятся безвольными рабами на галерах?
Мне вот интересно, почему вы хотите переложить на программистов ответственность за выполнение сроков? Вам кажется, что они без этого становятся безвольными рабами на галерах?
5 лет опыта управления разработкой SaaS'ов для банков, бюро кредитных историй, информационно-аналитических систем. Я просто заблуждаюсь…
то, что вы много управляли не значит, что управляли успешно.
Давайте не будем ставить под сомнения мои профессиональные качества, я ведь не рассказываю вам, какой вы программист?
Успешность моего управления можно выразить в цифрах
0 увольнений за 3 года
0 конфликтов в комманде за 3 года
4 крупных проекта за 5 лет
За последние два года самое сильное опоздание по срокам — 2 дня
Успешность моего управления можно выразить в цифрах
0 увольнений за 3 года
0 конфликтов в комманде за 3 года
4 крупных проекта за 5 лет
За последние два года самое сильное опоздание по срокам — 2 дня
А я и не рассказываю, что мой метод программирования — единственно правильный.
1. Если у вас есть опыт, пусть и успешный не значит, что отличный опыт других менеджеров — ошибочный.
2. Если у вас есть опыт постановки сроков для шаблонных задач своих программистов не значит, что у всех программистов шаблонные задачи, которые способен оценить менеджер.
В этом два ваши заблуждения, вот и всё)
1. Если у вас есть опыт, пусть и успешный не значит, что отличный опыт других менеджеров — ошибочный.
2. Если у вас есть опыт постановки сроков для шаблонных задач своих программистов не значит, что у всех программистов шаблонные задачи, которые способен оценить менеджер.
В этом два ваши заблуждения, вот и всё)
1. Не опыт ошибочный. Опыт не может быть ошибочным. Эффект от управления разный. Вы мыслите как работник (это не укор вам), а нужно посмотреть на проблему с другой стороны. Проблема заключается в том, что ответственность переносится на конечного работника. Это неправильно, потому что прослойка менеджмента тогда не нужна как класс.
2. Опять же, откуда у вас информация про шаблонность задач моих программистов? Не надо скатываться на личное, это плохой путь. Опять же, если вы не можете себе представить, что кто-то может оценить сроки лучше вас, то это же не значит, что это невозможно.
Все упускают из вида, что программист может оценить только свои локальные задачи, но не глобальные. Попробуйте оценить, сколько времени потратите не лично вы на создание новой игры, а компания в целом. Для ответа на этот вопрос вам придется обложиться статистикой выполнения предыдущих планов, кучей табличек и графиками, оценить интеллектуальный потенциал компании на текущий момент времени, наложить туда бизнес-планы текущие, и многое другое сделать. Это несколько отличается от простого решения сложить оценки каждого работника и умножить на поправочный коэффициент, правда?
Может это не мои заблуждения, а ваши? :)
2. Опять же, откуда у вас информация про шаблонность задач моих программистов? Не надо скатываться на личное, это плохой путь. Опять же, если вы не можете себе представить, что кто-то может оценить сроки лучше вас, то это же не значит, что это невозможно.
Все упускают из вида, что программист может оценить только свои локальные задачи, но не глобальные. Попробуйте оценить, сколько времени потратите не лично вы на создание новой игры, а компания в целом. Для ответа на этот вопрос вам придется обложиться статистикой выполнения предыдущих планов, кучей табличек и графиками, оценить интеллектуальный потенциал компании на текущий момент времени, наложить туда бизнес-планы текущие, и многое другое сделать. Это несколько отличается от простого решения сложить оценки каждого работника и умножить на поправочный коэффициент, правда?
Может это не мои заблуждения, а ваши? :)
Сравнение программирования со строительством не так уж и ново, и в нем есть изрядное рациональное зерно. Правда, должен сказать, что за все время, что я работаю, у меня был всего один случай, когда я делал два очень похожих проекта. Да и то, надо сказать, что, при всей их схожести (виртуальные миры на одной и той же платформе с одной и той же командой) различий и нюансов оказалось достаточно для того, чтобы анализ сроков пришлось вести полностью заново.
Но, на самом деле, это всё не так уж и важно. Просто, похоже, мы с Вами являемся сторонниками разных методик и идеологий построения команды. Вам более нравится традиционная модель, с авторитетным — и авторитарным — начальством и с достаточно пассивными подчинёнными. Что ж, у нее есть изрядные достоинства. Например, намного проще и дешевле найти работников, от которых требуется исполнительность и узкая специализация.
Но мне ближе иная модель, в которой начальник является равноправным членом команды, и ответственность делится между всеми членами коллектива. На мой взгляд, такие команды, хоть и труднее в создании, но гораздо здоровее и более устойчивы. У традиционной команды начальник — это центральная точка отказа. Заболел он, впал в депрессию или просто ушёл — всё, работа встала. У команды моего типа отсутствие начальника вызывает чисто технические неудобства, и, в принципе, команда может спокойно продолжать работу в течении изрядного времени. Да и мне приятнее ощущать себя полноправным участником процесса, а не этаким Равшаном — Джумшутом от программирования. :)
Но, на самом деле, это всё не так уж и важно. Просто, похоже, мы с Вами являемся сторонниками разных методик и идеологий построения команды. Вам более нравится традиционная модель, с авторитетным — и авторитарным — начальством и с достаточно пассивными подчинёнными. Что ж, у нее есть изрядные достоинства. Например, намного проще и дешевле найти работников, от которых требуется исполнительность и узкая специализация.
Но мне ближе иная модель, в которой начальник является равноправным членом команды, и ответственность делится между всеми членами коллектива. На мой взгляд, такие команды, хоть и труднее в создании, но гораздо здоровее и более устойчивы. У традиционной команды начальник — это центральная точка отказа. Заболел он, впал в депрессию или просто ушёл — всё, работа встала. У команды моего типа отсутствие начальника вызывает чисто технические неудобства, и, в принципе, команда может спокойно продолжать работу в течении изрядного времени. Да и мне приятнее ощущать себя полноправным участником процесса, а не этаким Равшаном — Джумшутом от программирования. :)
Немного не так.
Я стараюсь защищать команду от любых попыток бизнеса нарушить ход разработки своими постоянно меняющимися требованиями. Это не значит, что я не подстраиваюсь под бизнес, это значит, что любые изменения вектора должны быть продуманы и хорошо ложиться в общую стратегию достижения цели, не нарушая сроков и договоренностей.
Внутри команды идет спокойный процесс разработки, предоставлено много свобод. Но нет домоклова меча ответственности за любые неправильные сроки или оценки. А раз нет конфликтов — идет концентрация на достижении основной цели разработчика, писать код. Наслаждайся работой, остальное — не твои заботы.
Фактически, для управления сверху не существует разработчиков, есть только производственный менеджер.
Так строится команда, которая доверяет друг другу, не конфликтует (нет наказания за срыв сроков, а причину неудачи обычно ищут на стороне), которая сохраняет высокий темп разработки, потому что четко задан вектор.
Я стараюсь защищать команду от любых попыток бизнеса нарушить ход разработки своими постоянно меняющимися требованиями. Это не значит, что я не подстраиваюсь под бизнес, это значит, что любые изменения вектора должны быть продуманы и хорошо ложиться в общую стратегию достижения цели, не нарушая сроков и договоренностей.
Внутри команды идет спокойный процесс разработки, предоставлено много свобод. Но нет домоклова меча ответственности за любые неправильные сроки или оценки. А раз нет конфликтов — идет концентрация на достижении основной цели разработчика, писать код. Наслаждайся работой, остальное — не твои заботы.
Фактически, для управления сверху не существует разработчиков, есть только производственный менеджер.
Так строится команда, которая доверяет друг другу, не конфликтует (нет наказания за срыв сроков, а причину неудачи обычно ищут на стороне), которая сохраняет высокий темп разработки, потому что четко задан вектор.
Про защиту команды — это замечательно. Согласен на сто процентов. Так и должно быть. Но вот про дамоклов меч я не понял. Всё же, что происходит, когда сроки нарушаются и проект начинает запаздывать?
И про поиски причины неудачи на стороне мне тоже не ясно. А если всё же причина кроется внутри команды, тогда что?
И про поиски причины неудачи на стороне мне тоже не ясно. А если всё же причина кроется внутри команды, тогда что?
Нарушение сроков может происходить по разным причинам, одна из них — изменение требований по ходу разработки. Тут ничего не делается, устанавливается новый план работ и разработка ведется дальше.
Вторая причина нарушения сроков — влияние внешних факторов. Например, не была вовремя подготовлена инфрастуктура. Тут аналогично первому варианту.
Третья причина — низкая эффективность команды. Тут нужно искать способы повышения эффективности (прямая задача менеджера). Это может достигаться весьма примитивными методами, например устраивать день молчания во вторник, когда все в команде играют в молчанку. Выигравший получает вкусную плюшку.
Четвертая — низкое качество инструментария. Нужно принимать или решение смены инструментария, или твикать и точить старый.
Вторая причина нарушения сроков — влияние внешних факторов. Например, не была вовремя подготовлена инфрастуктура. Тут аналогично первому варианту.
Третья причина — низкая эффективность команды. Тут нужно искать способы повышения эффективности (прямая задача менеджера). Это может достигаться весьма примитивными методами, например устраивать день молчания во вторник, когда все в команде играют в молчанку. Выигравший получает вкусную плюшку.
Четвертая — низкое качество инструментария. Нужно принимать или решение смены инструментария, или твикать и точить старый.
Прораб после вопроса спросит у штукатура, маляра и плиточника, сколько займет их работа, сделает поправочный коэффициент на сложность, учтет сроки доставки материалов в ваш район и назовет вам результирующую. Практически как менеджер.
З.Ы. В настоящее время у меня 2 ремонта, так что знаю, о чем говорю
З.Ы. В настоящее время у меня 2 ремонта, так что знаю, о чем говорю
Ув. автор.
Может быть Ваш менеджер должен еще вам кофе по утрам делать и ботинки чистить перед выходом с офиса?
Что бы у Вас не дай бог настроение работать не испортилось.
Вот почитайте пост «hoack», он написал абсолютно точно то, что Вам нужно научиться делать.
Может быть Ваш менеджер должен еще вам кофе по утрам делать и ботинки чистить перед выходом с офиса?
Что бы у Вас не дай бог настроение работать не испортилось.
Вот почитайте пост «hoack», он написал абсолютно точно то, что Вам нужно научиться делать.
А вообще жесть, Вы столько говорите про уважение к себе, а Вы хоть раз интересовались почему менеджеры себя так ведут и чем Вы можете ему помочь, что бы всем легче жилось?
1) Сколько времени займет покрасить комнату неизвестной площади? Полчаса на метр квадратный при условии восьмичасового рабочего дня, ок ответ?
По типовым и шаблонным задачам менеджер, пожалуй, отвлекать и не станет. А там, где его технической компетенции не хватает, ему правильней обратиться к программисту, чтобы получить оценку с потолка «технического», а не «менеджерского», тот потолок ближе к реальности.
2) Ну тут косяк менеджера, да. Должен был ещё на третий день участливо поинтересоваться, чтобы внести коррективы в план, ещё что-нибудь сделать для улучшения процесса со своей стороны. Опять же, с его стороны всё выглядит так: программист делает чёрную коробушку, обещал за N времени, а прошло уже 3N. Что-то не так в консерватории. А если программист сам не запросил времени на какие-то исправления-допиливания — то сам себе бяку сделал.
По типовым и шаблонным задачам менеджер, пожалуй, отвлекать и не станет. А там, где его технической компетенции не хватает, ему правильней обратиться к программисту, чтобы получить оценку с потолка «технического», а не «менеджерского», тот потолок ближе к реальности.
2) Ну тут косяк менеджера, да. Должен был ещё на третий день участливо поинтересоваться, чтобы внести коррективы в план, ещё что-нибудь сделать для улучшения процесса со своей стороны. Опять же, с его стороны всё выглядит так: программист делает чёрную коробушку, обещал за N времени, а прошло уже 3N. Что-то не так в консерватории. А если программист сам не запросил времени на какие-то исправления-допиливания — то сам себе бяку сделал.
Сколько времени займет покрасить комнату неизвестной площади? Полчаса на метр квадратный при условии восьмичасового рабочего дня, ок ответ?
К сожалению, при такой постановке исходной задачи гораздо чаще нужно не красить комнату, а клеить обои или плитку, а после прихода на объект выясняется, что в комнате нет ни одного прямого угла, а перепад высоты стен таков, что если нарезать обои ровно, то он будет виден даже слепому.
По этому полчаса на метр^2 — это слишком жесткая оценка, которая не учитывает невысказанных нюансов задачи и гораздо более правильной была бы оценка от 0,5 часа до N дней (недель, месяцев) на метр^2.
Точное ТЗ всегда позволяет достать это ТЗ и показать в ответ на вопросы: «А почему это не так?».
И если ТЗ всё же точное, то сроки уже можно ставить правильно.
тут правильно выше писали: чем больше опыта, наработок и умения — тем точнее устанавливаются сроки. А уж если есть точное ТЗ…
И если ТЗ всё же точное, то сроки уже можно ставить правильно.
тут правильно выше писали: чем больше опыта, наработок и умения — тем точнее устанавливаются сроки. А уж если есть точное ТЗ…
Очень аргументированные ответы :)
Чушь.
Если ТЗ полное, то в нем по пунктам расписано, что должно быть сделано. В этом случае нет проблем назвать максимально точные сроки.
Указанные вами методики для оценки сроков, никак не противоречат этому утверждению.
Если ТЗ полное, то в нем по пунктам расписано, что должно быть сделано. В этом случае нет проблем назвать максимально точные сроки.
Указанные вами методики для оценки сроков, никак не противоречат этому утверждению.
Точное ТЗ…
Всех нас спасет…
На один этап…
А потом не будет клиента, менеджера и программиста.
Неужели не очевидно, что точное ТЗ — это прерогатива больших компаний работающих над одним большим проектом. ИТ-рынок состоит на 90% из малых команд, в которых:
а) написание точного ТЗ непозволительная роскошь;
б) следование точному ТЗ (а оно убогое по пункту а) — потери в ближайшем будущем.
Всех нас спасет…
На один этап…
А потом не будет клиента, менеджера и программиста.
Неужели не очевидно, что точное ТЗ — это прерогатива больших компаний работающих над одним большим проектом. ИТ-рынок состоит на 90% из малых команд, в которых:
а) написание точного ТЗ непозволительная роскошь;
б) следование точному ТЗ (а оно убогое по пункту а) — потери в ближайшем будущем.
Ходить по воде и разрабатывать программы согласно ТЗ очень просто, если они заморожены (с) E. Berard
Мы, наверное, говорим с Вами о разных масштабах: если Вам предлагают написать сайт, дают ТЗ к нему, то какие проблемы в сроках? Если Вам предлагают сделать некий обработчик файлов или внести свою лепту в общий проект, то, опять же — что трудного установить сроки?
Когда Вам предлагают ТЗ, в котором надо сделать всё с нуля и половина или больше зависит не от Вас — да, конечно. Тут уже работают методики с попеременным успехом.
Приведу пример с Вашим же «копаем до обеда»: когда Вы не знаете, где и какие коммуникации и трубы проходят, где какая почва/земля/камень, Вы и не дадите никаких сроков.
Но если у Вас есть планы всего, чего нужно, включая геодезическую разведку, у Вас есть определённые инструменты (25 ямокопателей и три экскаватора), то в чём сложность дать максимально точную оценку времени какому-то почти стандартному действию?
Согласен, есть вещи, которые нужно творить как художнику. Вдохновение, образ, случайное даже озарение. Но в большинстве своём это стандартная работа: портрет, шарж, натюрморт, чеканка, если хотите.
Когда Вам предлагают ТЗ, в котором надо сделать всё с нуля и половина или больше зависит не от Вас — да, конечно. Тут уже работают методики с попеременным успехом.
Приведу пример с Вашим же «копаем до обеда»: когда Вы не знаете, где и какие коммуникации и трубы проходят, где какая почва/земля/камень, Вы и не дадите никаких сроков.
Но если у Вас есть планы всего, чего нужно, включая геодезическую разведку, у Вас есть определённые инструменты (25 ямокопателей и три экскаватора), то в чём сложность дать максимально точную оценку времени какому-то почти стандартному действию?
Согласен, есть вещи, которые нужно творить как художнику. Вдохновение, образ, случайное даже озарение. Но в большинстве своём это стандартная работа: портрет, шарж, натюрморт, чеканка, если хотите.
от 10 до 25 минут.
Если хотите точности — напишите ТЗ: в какое время суток я поеду, на каком транспорте буду добираться.
Я понимаю, что Вы хотите сказать: непредвиденные обстоятельства, НЛО и прочее, но, поверьте, утрировать можно абсолютно всё.
И если не уметь планировать своё время или время своей работы, то подозревать других в таких же проблемах как-то несерьёзно, что ли.
p.s. мне вот действительно интересно, точность времени поездки до секунды — это как? С Вас реально хотя бы раз требовали такие сроки?
— Вася, мне нужен проект, вот точное ТЗ. Мне нужны сроки.
— Я думаю, это 10-12 дней.
— Нет, Вася, точнее!
— 967 960 секунды, мой генерал!!!
Если хотите точности — напишите ТЗ: в какое время суток я поеду, на каком транспорте буду добираться.
Я понимаю, что Вы хотите сказать: непредвиденные обстоятельства, НЛО и прочее, но, поверьте, утрировать можно абсолютно всё.
И если не уметь планировать своё время или время своей работы, то подозревать других в таких же проблемах как-то несерьёзно, что ли.
p.s. мне вот действительно интересно, точность времени поездки до секунды — это как? С Вас реально хотя бы раз требовали такие сроки?
— Вася, мне нужен проект, вот точное ТЗ. Мне нужны сроки.
— Я думаю, это 10-12 дней.
— Нет, Вася, точнее!
— 967 960 секунды, мой генерал!!!
У меня создаётся впечатление, что Вы ни разу в жизни не выдержали никаких сроков.
Ни разу их не устанавливали.
Потому что, скорее всего, многого не знаете.
И даже не пытаетесь узнать.
К Вашему вопросу про самокат:
Во-первых, последний раз я катался на самокате году эдак в 85-86. Я Вам больше скажу: путь от дома до работы в 13:00 на указанной модели самоката — это задача абсолютно нетривиальная для 98,5%, а то и более, исполнителей. Значит, либо я не возьмусь за такую работу, либо буду говорить о приближенных сроках, если нужно — с обоснованием.
Во-вторых, я ещё раз повторюсь: покажите мне хоть один пример, когда заказчик требует такую точность? Всегда называют максимальные сроки. Если Вам говорят: «Добавь сюда кнопку запуска другой формы. Минут 10-15 хватит?», Вы же понимаете, что либо хватит, либо нет? или даже тогда требуют секунды? Для маразма, вроде, рано ещё.
А давайте тогда я тоже буду таким же дотошным? По Вашему ТЗ я «доеду» до работы за 52 минуты и 43 секунды.
Ни разу их не устанавливали.
Потому что, скорее всего, многого не знаете.
И даже не пытаетесь узнать.
К Вашему вопросу про самокат:
Во-первых, последний раз я катался на самокате году эдак в 85-86. Я Вам больше скажу: путь от дома до работы в 13:00 на указанной модели самоката — это задача абсолютно нетривиальная для 98,5%, а то и более, исполнителей. Значит, либо я не возьмусь за такую работу, либо буду говорить о приближенных сроках, если нужно — с обоснованием.
Во-вторых, я ещё раз повторюсь: покажите мне хоть один пример, когда заказчик требует такую точность? Всегда называют максимальные сроки. Если Вам говорят: «Добавь сюда кнопку запуска другой формы. Минут 10-15 хватит?», Вы же понимаете, что либо хватит, либо нет? или даже тогда требуют секунды? Для маразма, вроде, рано ещё.
А давайте тогда я тоже буду таким же дотошным? По Вашему ТЗ я «доеду» до работы за 52 минуты и 43 секунды.
Как так?
С чего вы взяли, что неправда-то?
Ваш самокат выдерживает 65 кг нагрузки, во мне — 95.
Всю дорогу по кратчайшему расстоянию я буду идти пешком и нести его на себе.
5,84 км. пути.
При средней скорости пешехода 5 км/ч, моей способности ходить чуть быстрее — я рассчитываю именно это время.
Плюс я делаю поправку на время года, погодные условия, моё состояние здоровья (я же часть работающий системы?) и ещё кучу других, не указанных в ТЗ, факторах.
Исходя из всего вышеперечисленного, я говорю именно о таком времени.
Я, кстати, при благоприятных условиях могу уложиться в более быстрые сроки. Но если Вам важно именно указанное мною время — 52 минуты 43 секунды, корректируя нагрузку, скорость передвижения и остальные факторы я прибуду на работу РОВНО через 52 минуты 43 секунды.
Вы спорите только ради того, чтобы спорить. Ещё раз повторю: Ваша некомпетентность и неспособность следовать ТЗ, планировать свою работу, учитывать подводные камни и максимальное время их решения — это Ваше дело.
За сим — адью, мон шер.
Если Вам инетресно, можете писать в ЛС, я подробно отвечу Вам на любой пример, а если будет достаточно времени — даже подскажу что-либо.
С чего вы взяли, что неправда-то?
Ваш самокат выдерживает 65 кг нагрузки, во мне — 95.
Всю дорогу по кратчайшему расстоянию я буду идти пешком и нести его на себе.
5,84 км. пути.
При средней скорости пешехода 5 км/ч, моей способности ходить чуть быстрее — я рассчитываю именно это время.
Плюс я делаю поправку на время года, погодные условия, моё состояние здоровья (я же часть работающий системы?) и ещё кучу других, не указанных в ТЗ, факторах.
Исходя из всего вышеперечисленного, я говорю именно о таком времени.
Я, кстати, при благоприятных условиях могу уложиться в более быстрые сроки. Но если Вам важно именно указанное мною время — 52 минуты 43 секунды, корректируя нагрузку, скорость передвижения и остальные факторы я прибуду на работу РОВНО через 52 минуты 43 секунды.
Вы спорите только ради того, чтобы спорить. Ещё раз повторю: Ваша некомпетентность и неспособность следовать ТЗ, планировать свою работу, учитывать подводные камни и максимальное время их решения — это Ваше дело.
За сим — адью, мон шер.
Если Вам инетресно, можете писать в ЛС, я подробно отвечу Вам на любой пример, а если будет достаточно времени — даже подскажу что-либо.
Пообедал, настроение поднялось :)
Я где-то писал про GPS и часы? Откуда это взято? Ах, Ваше желание собственной значимости и всё усложнить.
Кратчайший путь я знаю. Вы не поверите, сколько я ещё всего знаю о своём маршруте из дома на работу и обратно. Это заранее квалифицирует меня как опытного исполнителя, а не как какого-то растяпу, который живёт на одном и том же месте и ходит на одну и ту же работу, но не знает даже этого.
При чём тут невпихуемое? :) Не понимаю. У Вас есть точное ТЗ, с которым согласились все остальные и Вы в том числе, раз Вы взялись над ним работать.
Так в чём проблема-то сделать так, как продиктовано условием?
Нерешаемая задача? Умный человек?
А давайте-ка без лишних слов: приведите конкретный пример своей работы, когда Вы не можете дать временную оценку по более-менее точному ТЗ.
Что мы все вокруг да около? Если хотите, я Вам свои примеры приведу.
У Вас одни только разговоры. Какие-то выдуманные и мистические случаи и требования. И когда Вам даются прямые ответы, Вы начинаете придумывать и брать с потолка что-то несуразное.
Считаете, что Вы — правы? Хотя бы один пример из собственной практики на всеобщее обозрение можете выдвинуть?
p.s. очень хочется надеяться, что Вы руководствуетесь первой цитатой Тургенева, а не мне приходится выбирать из двух последних…
Я где-то писал про GPS и часы? Откуда это взято? Ах, Ваше желание собственной значимости и всё усложнить.
Кратчайший путь я знаю. Вы не поверите, сколько я ещё всего знаю о своём маршруте из дома на работу и обратно. Это заранее квалифицирует меня как опытного исполнителя, а не как какого-то растяпу, который живёт на одном и том же месте и ходит на одну и ту же работу, но не знает даже этого.
При чём тут невпихуемое? :) Не понимаю. У Вас есть точное ТЗ, с которым согласились все остальные и Вы в том числе, раз Вы взялись над ним работать.
Так в чём проблема-то сделать так, как продиктовано условием?
Нерешаемая задача? Умный человек?
А давайте-ка без лишних слов: приведите конкретный пример своей работы, когда Вы не можете дать временную оценку по более-менее точному ТЗ.
Что мы все вокруг да около? Если хотите, я Вам свои примеры приведу.
У Вас одни только разговоры. Какие-то выдуманные и мистические случаи и требования. И когда Вам даются прямые ответы, Вы начинаете придумывать и брать с потолка что-то несуразное.
Считаете, что Вы — правы? Хотя бы один пример из собственной практики на всеобщее обозрение можете выдвинуть?
p.s. очень хочется надеяться, что Вы руководствуетесь первой цитатой Тургенева, а не мне приходится выбирать из двух последних…
Ну, что ж это такое.
Если бы мне нужно было, то я бы это оговорил: для выполнения данного ТЗ прошу выдать то-то и то-то.
Но! *вот здесь прошу отнестись со всей серьёзностью*
Когда я пишу код, я не требую себе компьютера, потому что это подразумевается.
Когда я пишу код, я предполагаю, что с ним будут работать пользователи. Или механизмы.
Если мне потребуется, чтобы код работал с унитазом орбитальной станции — я попрошу доступ к модели унитаза или к самой станции.
Если у меня есть, чем измерить время, зачем мне что-то выдумывать?
Может быть Вы код пишете на зановопридумываемом для каждой задаче своём собственном языке?
В нашем с Вами случае, у меня есть и часы, и ГПС на смартфоне, и часы там же. Как и секундомеры, хотя в Вашем же ТЗ ни слова не говорилось о необходимости использовать такие приборы. Но тем не менее — они уже есть, если хотите. Но в ТЗ их не было.
Давайте посмотрим на это с другой стороны: был поставлен вопрос, был дан ответ. Кстати, ответ был дан даже с необязательными к нему пояснениями и обоснованиями.
По каким критериям он Вас не устраивает?
Если бы мне нужно было, то я бы это оговорил: для выполнения данного ТЗ прошу выдать то-то и то-то.
Но! *вот здесь прошу отнестись со всей серьёзностью*
Когда я пишу код, я не требую себе компьютера, потому что это подразумевается.
Когда я пишу код, я предполагаю, что с ним будут работать пользователи. Или механизмы.
Если мне потребуется, чтобы код работал с унитазом орбитальной станции — я попрошу доступ к модели унитаза или к самой станции.
Если у меня есть, чем измерить время, зачем мне что-то выдумывать?
Может быть Вы код пишете на зановопридумываемом для каждой задаче своём собственном языке?
В нашем с Вами случае, у меня есть и часы, и ГПС на смартфоне, и часы там же. Как и секундомеры, хотя в Вашем же ТЗ ни слова не говорилось о необходимости использовать такие приборы. Но тем не менее — они уже есть, если хотите. Но в ТЗ их не было.
Давайте посмотрим на это с другой стороны: был поставлен вопрос, был дан ответ. Кстати, ответ был дан даже с необязательными к нему пояснениями и обоснованиями.
По каким критериям он Вас не устраивает?
М-м-м… Даже не знаю, как и ответить. Наверное, потому что я так оценил своё время выполнения поставленной задачи. И я выдержу сроки.
Если Вас, как заказчика, оно не устраивает, то нанимайте более быстрого и качественного исполнителя. Это конкуренция — не слышали о таком?
Вы ещё помните первоначальный вопрос полемики?
Вы говорите, что нереально определить сроки по более-менее точному ТЗ.
Я говорю, что даже по тому ТЗ, какое написали Вы, без особого труда можно дать оценку выполнения задачи, самому при это просчитав некоторые нюансы и моменты, не указанные в ТЗ (если оно вообще надо, можно сделать строго по ТЗ).
Вы не умеете или не хотите этого делать? И кто в этом виноват?
Если Вас, как заказчика, оно не устраивает, то нанимайте более быстрого и качественного исполнителя. Это конкуренция — не слышали о таком?
Вы ещё помните первоначальный вопрос полемики?
Вы говорите, что нереально определить сроки по более-менее точному ТЗ.
Я говорю, что даже по тому ТЗ, какое написали Вы, без особого труда можно дать оценку выполнения задачи, самому при это просчитав некоторые нюансы и моменты, не указанные в ТЗ (если оно вообще надо, можно сделать строго по ТЗ).
Вы не умеете или не хотите этого делать? И кто в этом виноват?
М-да… видимо, я тут явно забавлюсь :)
Часы (измеритель) мне необходимы для контроля. И если через какое-то время меня попросят сделать схожую задачу или как часть большей задачи, я буду опираться ещё и на эти, полученные в этом Вашем ТЗ, измерения.
А что Вас не устраивает в моём ответе? Вы не ответили или пропустили мимо ушей много моих вопросов.
Вас не устраивает время, обозначенное мной? Вам нужно быстрее? Я могу. Только тогда предложу внести изменения в ТЗ. Потому что оно уже неверно изначально: я же не еду на самокате, а несу его. Но он лёгкий, путь недалёкий, а мне и не сложно абсолютно его Вам донести.
Вы пытаетесь сказать, что задача делается так, как делается и о времени говорить некорректно? Неправда Ваша. Я спрошу Вас и Колю:
— Сколько времени Вам потребуется для написания и внедрения модуля оплаты на удалённой точке офиса?
И Коля ответит, подумав:
— 4 дня.
А меня этот ответ устроит. Потому что, если Коля сделает быстрее — будет даже лучше. А вот если не сделает, то либо он плохо подумал перед ответом и тут возникают варианты: верить ему, не верить, самому ставить его во временные рамки, либо он не справился с задачей, которую мне Иван, Толя и Володя сделали за те же 4 дня. И тогда я буду менять Колю.
А что ответите Вы? Хотя бы попробуйте? Я Вам могу изложить то, что Вы уже «знаете», а то, о чём Вы не знаете — будете проинформированы.
Часы (измеритель) мне необходимы для контроля. И если через какое-то время меня попросят сделать схожую задачу или как часть большей задачи, я буду опираться ещё и на эти, полученные в этом Вашем ТЗ, измерения.
А что Вас не устраивает в моём ответе? Вы не ответили или пропустили мимо ушей много моих вопросов.
Вас не устраивает время, обозначенное мной? Вам нужно быстрее? Я могу. Только тогда предложу внести изменения в ТЗ. Потому что оно уже неверно изначально: я же не еду на самокате, а несу его. Но он лёгкий, путь недалёкий, а мне и не сложно абсолютно его Вам донести.
Вы пытаетесь сказать, что задача делается так, как делается и о времени говорить некорректно? Неправда Ваша. Я спрошу Вас и Колю:
— Сколько времени Вам потребуется для написания и внедрения модуля оплаты на удалённой точке офиса?
И Коля ответит, подумав:
— 4 дня.
А меня этот ответ устроит. Потому что, если Коля сделает быстрее — будет даже лучше. А вот если не сделает, то либо он плохо подумал перед ответом и тут возникают варианты: верить ему, не верить, самому ставить его во временные рамки, либо он не справился с задачей, которую мне Иван, Толя и Володя сделали за те же 4 дня. И тогда я буду менять Колю.
А что ответите Вы? Хотя бы попробуйте? Я Вам могу изложить то, что Вы уже «знаете», а то, о чём Вы не знаете — будете проинформированы.
А как же работаете Вы? Как придётся? «Как сделаю, так и сделаю! И вообще, я — звезда!»?
У меня контроль — это контроль.
У меня всегда параллельно куча задач. Плюс личное время, личные мысли, жизненные ситуации. Я знаю, что сейчас у меня стоят сроки — и я не отвлекаюсь.
Я умею расставлять приоритеты.
Если Вы работаете всегда только над одной задачей, то у вас вообще всё просто: Вас никтьо не отвлекает, и Вы должны мгновенно говорить, сколько Вам надо времени на неё.
Мы с Вами говорим (надеюсь) о том, что если с Вас спрашивают сроки, а Вы не можете адекватно их оценить, то Вы — пшик, а не специалист. А если Вы действительно занимаетесь исключительно нетривиальными идеями и вдохновением, то про какие сроки идёт речь?
Вы не ответили ни на один мой вопрос.
Вы неумело и очень натянуто пытались найти в моих словах промашку и нелепицу.
Вы не в состоянии ни привести пример, ни оценить, ни ответить.
Вы самое слабое звено.
Прощайте!
p.s. И — да, я достаточно развит, чтобы понять Ваши мысли и слова в том смысле, которые Вы в них вложили. Это я про «погонялы».
p.s. Я бы мог спросить, кто Вы, откуда, чем занимаетесь и сколько получаете. А если сумма или положение меня бы заинтересовало, то спокойно занять Вашу должность хотя бы потому, что умею говорить о сроках.
Но что-то мне подсказывает, что заинтересованности не будет.
Потому, советую Вам прислушаться к тому, что Вы же цитируете у себя в профиле.
У меня контроль — это контроль.
У меня всегда параллельно куча задач. Плюс личное время, личные мысли, жизненные ситуации. Я знаю, что сейчас у меня стоят сроки — и я не отвлекаюсь.
Я умею расставлять приоритеты.
Если Вы работаете всегда только над одной задачей, то у вас вообще всё просто: Вас никтьо не отвлекает, и Вы должны мгновенно говорить, сколько Вам надо времени на неё.
Мы с Вами говорим (надеюсь) о том, что если с Вас спрашивают сроки, а Вы не можете адекватно их оценить, то Вы — пшик, а не специалист. А если Вы действительно занимаетесь исключительно нетривиальными идеями и вдохновением, то про какие сроки идёт речь?
Вы не ответили ни на один мой вопрос.
Вы неумело и очень натянуто пытались найти в моих словах промашку и нелепицу.
Вы не в состоянии ни привести пример, ни оценить, ни ответить.
Вы самое слабое звено.
Прощайте!
p.s. И — да, я достаточно развит, чтобы понять Ваши мысли и слова в том смысле, которые Вы в них вложили. Это я про «погонялы».
p.s. Я бы мог спросить, кто Вы, откуда, чем занимаетесь и сколько получаете. А если сумма или положение меня бы заинтересовало, то спокойно занять Вашу должность хотя бы потому, что умею говорить о сроках.
Но что-то мне подсказывает, что заинтересованности не будет.
Потому, советую Вам прислушаться к тому, что Вы же цитируете у себя в профиле.
Как — что?
А Вы не в курсе, что работа ИТ загоняет специалиста в рамки саморазвития, которое должно быть подчас ежедневным, дабы не упустить что-то вновь появившееся?
И если я не буду интересоваться Хабром, другими сайтами, не читать новости и т.п., то я просто не буду в курсе событий, отставать от прогресса и думать «как же это заставить работать», когда это уже придумано и работает.
К тому же, в данным момент времени передо мной стоят задачи, зависящие не только от меня. В результате чего я жду ответа от других отделов и организаций, а себе позволяю обратиться к таким сайтам как Хабр после ударного труда.
А если учесть, что больше половины сроков я устанавливаю себе сам, то я теряюсь в том, как ответить *пожимает плечами*
А Вы не в курсе, что работа ИТ загоняет специалиста в рамки саморазвития, которое должно быть подчас ежедневным, дабы не упустить что-то вновь появившееся?
И если я не буду интересоваться Хабром, другими сайтами, не читать новости и т.п., то я просто не буду в курсе событий, отставать от прогресса и думать «как же это заставить работать», когда это уже придумано и работает.
К тому же, в данным момент времени передо мной стоят задачи, зависящие не только от меня. В результате чего я жду ответа от других отделов и организаций, а себе позволяю обратиться к таким сайтам как Хабр после ударного труда.
А если учесть, что больше половины сроков я устанавливаю себе сам, то я теряюсь в том, как ответить *пожимает плечами*
Маразм крепчал…
Техническое задание — это техническое задание.
Для Вас, наверное, будет откровением, но когда Вы готовите себе завтрак, Вы выполняете своё техническое задание. Оно может быть разным: покушать, или выпить горячего кофе и покушать, или встать, умыться, нарезать хлеб, налить в чайник воду и т.д.
Так вот, если Вы готовите впервые, неуверенны в себе, плохо готовите или что-то там ещё, то точное ТЗ (встать с правой ноги, перенести вес тела к столу, взять нож за ручку острой стороной лезвия вниз в направлении от себя) Вам будет в любом случае только на пользу.
Если Вы опытный повар, то ТЗ, состоящее из одного «позавтракать» вообще не будет Вам как-то досаждать.
Если говорить о сроках, то Вы же прикидываете, что приготовить быстрокашку, омлет, бутерброд, творожную запеканку займёт примерно столько-то времени.
Поздравляю! Вы можете давать временную оценку своей работе!
И если Вы знаете свою профессию так же неплохо или даже хорошо, то что мешает Вам давать сроки на выполнение своей работы?
Ответьте хоть на один мой вопрос, в конце-то концов. Я ответил на все Ваши.
Вы уходите в дебри: сначала прицепились к часам, потом перекинулись на юридические документы.
Повторю ещё раз: приведите пример Вашей работы, которой нельзя дать временную оценку? Мне не нужны секунды. Раскрой страшную тайну — они никому не нужны. Но если верстальщик режет макет за 1-2 дня, то можно говорить о часах, после того как он взглянет на макет. Если программист пишет какой-либо модуль, то можно говорить и часах или днях, или неделях. Всё зависит от условий — т.е. ТЗ, которое кто-то, возможно даже он сам, заложил для реализации этого модуля.
Вы опять начинаете абстрагировать «а вот если что-то отходит от ТЗ» — да это не тот случай. С этим Вы сами согласились, написав «это верно».
Где пример? Что Вы делали вчера и делаете сегодня? Почему Вы не можете дать оценку по затрате времени на свои действия? У Вас при этом были точные ТЗ?
Кто составляет Вам ТЗ? Вы сами для себя составили хоть одно ТЗ? По сути, всё, то, что Вы планируете — это ТЗ. Почему в личной жизни Вы можете создавать ТЗ и определять на него определённые временные рамки, а на работе — нет?
Либо отвечайте, причём — аргументированно, либо не свистите.
Техническое задание — это техническое задание.
Для Вас, наверное, будет откровением, но когда Вы готовите себе завтрак, Вы выполняете своё техническое задание. Оно может быть разным: покушать, или выпить горячего кофе и покушать, или встать, умыться, нарезать хлеб, налить в чайник воду и т.д.
Так вот, если Вы готовите впервые, неуверенны в себе, плохо готовите или что-то там ещё, то точное ТЗ (встать с правой ноги, перенести вес тела к столу, взять нож за ручку острой стороной лезвия вниз в направлении от себя) Вам будет в любом случае только на пользу.
Если Вы опытный повар, то ТЗ, состоящее из одного «позавтракать» вообще не будет Вам как-то досаждать.
Если говорить о сроках, то Вы же прикидываете, что приготовить быстрокашку, омлет, бутерброд, творожную запеканку займёт примерно столько-то времени.
Поздравляю! Вы можете давать временную оценку своей работе!
И если Вы знаете свою профессию так же неплохо или даже хорошо, то что мешает Вам давать сроки на выполнение своей работы?
Ответьте хоть на один мой вопрос, в конце-то концов. Я ответил на все Ваши.
Вы уходите в дебри: сначала прицепились к часам, потом перекинулись на юридические документы.
Повторю ещё раз: приведите пример Вашей работы, которой нельзя дать временную оценку? Мне не нужны секунды. Раскрой страшную тайну — они никому не нужны. Но если верстальщик режет макет за 1-2 дня, то можно говорить о часах, после того как он взглянет на макет. Если программист пишет какой-либо модуль, то можно говорить и часах или днях, или неделях. Всё зависит от условий — т.е. ТЗ, которое кто-то, возможно даже он сам, заложил для реализации этого модуля.
Вы опять начинаете абстрагировать «а вот если что-то отходит от ТЗ» — да это не тот случай. С этим Вы сами согласились, написав «это верно».
Где пример? Что Вы делали вчера и делаете сегодня? Почему Вы не можете дать оценку по затрате времени на свои действия? У Вас при этом были точные ТЗ?
Кто составляет Вам ТЗ? Вы сами для себя составили хоть одно ТЗ? По сути, всё, то, что Вы планируете — это ТЗ. Почему в личной жизни Вы можете создавать ТЗ и определять на него определённые временные рамки, а на работе — нет?
Либо отвечайте, причём — аргументированно, либо не свистите.
ОМГ…
Написать программу «Hello World» для iPhone 5 — это всё ТЗ?
И Вы не имеете понятия? Вас надо гнать взашей, если Вы — программист или считаете себя таковым.
6 минут на поиски и изучение www.youtube.com/watch?v=PBv0lQWIUw0
Ну, и написать потом.
Т.о. через 2 минуты после вопроса Вы уже можете дать временную оценку выполнения описанной Вами же задачи. Вы приводите просто-таки фееричные примеры!
Дерзайте!
Если Вы не имеете понятия, как писать «Hello World» для iPhone 5, то каким образом к Вам попало это задание?
Это Ваше реальное задание на сегодня?
Вы делаете его первый раз?
Вы не можете аргументировать сроки?
Вы третий раз игнорируете вопрос и не приводите реальных примеров.
Из чего вполне логично вытекает вывод о том, что Вы уже осознали, что неправы, либо не хотите признавать, что почти все Ваши задачи подвергаются временной оценке, которую Вы делать не умеете или не хотите.
Я Вам могу привести кучу примеров из своей ежедневной работы, где в 80-85% случаях я даю временную оценку выполнения работы. И что оценка эта точна в тех допусках, которые устраивают всех.
Ваши советы почитать то и это — умиляют, но не более.
Третий раз прощаюсь с Вами, потому что вряд ли получу ответы на свои вопросы.
Написать программу «Hello World» для iPhone 5 — это всё ТЗ?
И Вы не имеете понятия? Вас надо гнать взашей, если Вы — программист или считаете себя таковым.
6 минут на поиски и изучение www.youtube.com/watch?v=PBv0lQWIUw0
Ну, и написать потом.
Т.о. через 2 минуты после вопроса Вы уже можете дать временную оценку выполнения описанной Вами же задачи. Вы приводите просто-таки фееричные примеры!
Дерзайте!
Если Вы не имеете понятия, как писать «Hello World» для iPhone 5, то каким образом к Вам попало это задание?
Это Ваше реальное задание на сегодня?
Вы делаете его первый раз?
Вы не можете аргументировать сроки?
Вы третий раз игнорируете вопрос и не приводите реальных примеров.
Из чего вполне логично вытекает вывод о том, что Вы уже осознали, что неправы, либо не хотите признавать, что почти все Ваши задачи подвергаются временной оценке, которую Вы делать не умеете или не хотите.
Я Вам могу привести кучу примеров из своей ежедневной работы, где в 80-85% случаях я даю временную оценку выполнения работы. И что оценка эта точна в тех допусках, которые устраивают всех.
Ваши советы почитать то и это — умиляют, но не более.
Третий раз прощаюсь с Вами, потому что вряд ли получу ответы на свои вопросы.
Астраханские мужчины много в чём могут посоревноваться с любыми докторами Стэнфорда.
А Вы не обязаны ничего и никому :)
Вы даже не в состоянии рассказать, чем Вы занимаетесь, обзывая это моей «больной фантазией». :)
Так что — стремитесь, учитесь, дерзайте!
И, может быть, Вы поймёте, что такое ТЗ, как оно работает и как Вы с ним должны работать.
А Вы не обязаны ничего и никому :)
Вы даже не в состоянии рассказать, чем Вы занимаетесь, обзывая это моей «больной фантазией». :)
Так что — стремитесь, учитесь, дерзайте!
И, может быть, Вы поймёте, что такое ТЗ, как оно работает и как Вы с ним должны работать.
Посмотрел ссылку.
Понял, почему мы с Вами говорим на разных языках.
«Сделать отправку смс» — Вы считаете это нормальным ТЗ?
Это не ТЗ.
И Вы делали это впервые?
А можно теперь спросить: если я буду нанимать Вас и мне потребуется реализовать отправку, что Вы мне ответите? Вспомните, что работа подобная уже была проделана и назовёте срок? Или будете придумывать велосипеды заново?
В Вашем примере:
1) Отсутствие ТЗ
2) Эта задача лично Вам делалась впервые.
Этих двух пунктов вполне достаточно.
Понял, почему мы с Вами говорим на разных языках.
«Сделать отправку смс» — Вы считаете это нормальным ТЗ?
Это не ТЗ.
И Вы делали это впервые?
А можно теперь спросить: если я буду нанимать Вас и мне потребуется реализовать отправку, что Вы мне ответите? Вспомните, что работа подобная уже была проделана и назовёте срок? Или будете придумывать велосипеды заново?
В Вашем примере:
1) Отсутствие ТЗ
2) Эта задача лично Вам делалась впервые.
Этих двух пунктов вполне достаточно.
Повторю ещё раз: приведите пример Вашей работы, которой нельзя дать временную оценку?
Сколька нужна времени нописать крутую игру для ифонов, токо бистро?
TheShock
Мне кажется, не лишне было причитать всю ветку и понять, что ключевые слова тут «техническое задание», «Вы — специалист», «Вы работаете с этим каждый день».
Вы — специалист написания игр для айфонов? Тогда Вы знаете, с чего начать, знаете к кому обратиться за дизайном, знаете его расценки и — ой, ой-ёй-ёй-ёй-ёй!!! — знаете, в какие сроки он вам этот дизайн сделает!!! Потому что дизайнеры — они тоже люди. Очень похожи, по крайней мере. И тоже дают сроки выполнения заказов.
Мне дальше продолжать?
Мне кажется, не лишне было причитать всю ветку и понять, что ключевые слова тут «техническое задание», «Вы — специалист», «Вы работаете с этим каждый день».
Вы — специалист написания игр для айфонов? Тогда Вы знаете, с чего начать, знаете к кому обратиться за дизайном, знаете его расценки и — ой, ой-ёй-ёй-ёй-ёй!!! — знаете, в какие сроки он вам этот дизайн сделает!!! Потому что дизайнеры — они тоже люди. Очень похожи, по крайней мере. И тоже дают сроки выполнения заказов.
Мне дальше продолжать?
Ну вообще-то я утрировал.
Как раз человек пытается объяснить вам, что обычно требования намного выше, чем предположения программиста.
Как раз человек пытается объяснить вам, что обычно требования намного выше, чем предположения программиста.
Но вот как — «обычно»?
С Вашего позволения, я полезу в бутылку: человек зарабатывает тем, что пишет код. Ему дают задание. Что мешает ему указать сроки выполнения работы?
Ну, вот представьте: Вас находит какие-либо частное мед.учреждение и даёт Вам ТЗ на разработку программы записи по талончикам (например).
там описан интерфейс, требования к платформе и много чего другого.
Вы прикидываете сколько времени займёт отрисовка форм. Сколько на код. И Ваш вердикт: «2 недели».
Заказчика это устраивает. Что же происходит потом? Одни начинают покупать столы для ПК, другие — настроивать сети, четвёртые — электропроводку.
Колесо закрутилось. Исполнитель — часть команды.
Объясните, как тогда вообще можно работать, если не прикидывать сроки?
Почему не прав директор или менеджер, требующий ответа? Потому что ему надо напрячь остальные службы для того, чтобы всё было готово как можно более сразу, а не по частям?
Вы программируете с напарником? Вам предложили работу? неужели никто не договаривается никогда «Коль, я вот эти вещи сделаю в ближаёшие два-три дня, с тебя — вот это и это, ладно?» Или же все плавают в незнании и небытие: ой, я же не знаю, когда он это допишет? вот когда допишет, тогда и я продолжу.
Ну, не так же всё… Что уж Вы.
С Вашего позволения, я полезу в бутылку: человек зарабатывает тем, что пишет код. Ему дают задание. Что мешает ему указать сроки выполнения работы?
Ну, вот представьте: Вас находит какие-либо частное мед.учреждение и даёт Вам ТЗ на разработку программы записи по талончикам (например).
там описан интерфейс, требования к платформе и много чего другого.
Вы прикидываете сколько времени займёт отрисовка форм. Сколько на код. И Ваш вердикт: «2 недели».
Заказчика это устраивает. Что же происходит потом? Одни начинают покупать столы для ПК, другие — настроивать сети, четвёртые — электропроводку.
Колесо закрутилось. Исполнитель — часть команды.
Объясните, как тогда вообще можно работать, если не прикидывать сроки?
Почему не прав директор или менеджер, требующий ответа? Потому что ему надо напрячь остальные службы для того, чтобы всё было готово как можно более сразу, а не по частям?
Вы программируете с напарником? Вам предложили работу? неужели никто не договаривается никогда «Коль, я вот эти вещи сделаю в ближаёшие два-три дня, с тебя — вот это и это, ладно?» Или же все плавают в незнании и небытие: ой, я же не знаю, когда он это допишет? вот когда допишет, тогда и я продолжу.
Ну, не так же всё… Что уж Вы.
Тут весь вопрос, как правильно в таких случаях общаться. Когда менеджер «выдавливает» из тебя сроки (причем ни ТЗ ни времени на анализ не предоставляет), ты должен абсолютно невозмутимо назвать тот срок, который тебе придет в голову, умноженный на 4. Это вызовет возмущение менеджера («А почему так долго?»). Это будет поводом, чтобы вместе с ним начать разбирать задачу на части и уточнять, что же конкретно надо сделать. В итоге вы получите более менее вразумительное ТЗ, а он в следующий раз будет более детально ставить тебе задачу. Если же менеджер «выдавил» из тебя срок, так и не удосужившись предоставить подробное ТЗ, то либо у тебя очень большая зарплата, и ты не хочешь конфликтовать с менеджером, либо ты обычный раб, и такое отношение к тебе будет всегда.
На самом деле, все эти проблемы полностью зависят от адекватности людей, участвующих в проекте.
Как в детском мультике «Если б мишки были пчелами...»
1. Адекватный менеджер, не будет требовать точные сроки исходя из ТЗ в одну строчку, он и спросит о примерных сроках, чтобы не с потолка брать цифры а хоть к какой-то реальности привязаться.
2. Адекватный менеджер понимает, что к такому ТЗ постоянно будет «доделки» и «переделки», и сразу обговорит это с заказчиком.
3. Адекватный менеджер понимает, что любое изменение требований ведет к изменению сроков разработки, и вопросы «а ты же обещал за 2 дня все сделать» не будут звучать на пустом месте.
4. Адекватный менеджер, думает над приоритетами задач, и если он подошел и сказал «блин, тут полная жопа, надо быстро», то это так и есть. И тут надо просто адекватно отнестись к этому, по идее в одной же лодке плывем…
5. Адекватный менеджер знает о проектных рисках не по наслышке и понимает к чему ведет смена технологий.
Точно также
1. Адекватный разработчик назовет «вилку» выполнения задачи. Например «обычно сделать козинку в магазине занимает 2-3 месяца». Или «на прошлом проекте мы сделали тэги в блоге за 3 дня». Т.е. хоть как-то привяжет менеджера к реальности.
2. Адекватный разработчик, напомнит менеджеру, что ТЗ не полное, и есть много нюансов, которые могут увеличить время в 2-3 раза, указав на некоторые из них, чтобы менеджер мог их обсудить с заказчиком.
3. Адекватный разработчик, при изменении требований, оповестит менеджера, что изменение этих требований отразится на времени и укажет причину и новые сроки.
4. Адекватный разработчик, кроме своих задач, должен видеть цель всего дела и понимать, что жизнь во круг изменяется часто и с этим ничего не поделаешь, бывают и действительно срочные задачи.
5. Адекватный разработчик, сможет объяснить, почему используется именно эта технология. И на вопрос а вот мы тут прочитали что Х круче, внятно объяснить почему им это не поможет. Технологии очень быстро развиваются, и руководство как ни странно общается и с другими людьми. И их интересует так же почему конкуренты используют Х и у них все хорошо, а мы используем У и у нас все плохо, может стоить потратить немного денег на закупку Х?
Дело осталось за малым. Собрать команду адекватных людей, которые вместо того чтобы выносить друг друг мозг взаимными придирками, соплями и понтами, будут делать одно общее дело…
Как в детском мультике «Если б мишки были пчелами...»
1. Адекватный менеджер, не будет требовать точные сроки исходя из ТЗ в одну строчку, он и спросит о примерных сроках, чтобы не с потолка брать цифры а хоть к какой-то реальности привязаться.
2. Адекватный менеджер понимает, что к такому ТЗ постоянно будет «доделки» и «переделки», и сразу обговорит это с заказчиком.
3. Адекватный менеджер понимает, что любое изменение требований ведет к изменению сроков разработки, и вопросы «а ты же обещал за 2 дня все сделать» не будут звучать на пустом месте.
4. Адекватный менеджер, думает над приоритетами задач, и если он подошел и сказал «блин, тут полная жопа, надо быстро», то это так и есть. И тут надо просто адекватно отнестись к этому, по идее в одной же лодке плывем…
5. Адекватный менеджер знает о проектных рисках не по наслышке и понимает к чему ведет смена технологий.
Точно также
1. Адекватный разработчик назовет «вилку» выполнения задачи. Например «обычно сделать козинку в магазине занимает 2-3 месяца». Или «на прошлом проекте мы сделали тэги в блоге за 3 дня». Т.е. хоть как-то привяжет менеджера к реальности.
2. Адекватный разработчик, напомнит менеджеру, что ТЗ не полное, и есть много нюансов, которые могут увеличить время в 2-3 раза, указав на некоторые из них, чтобы менеджер мог их обсудить с заказчиком.
3. Адекватный разработчик, при изменении требований, оповестит менеджера, что изменение этих требований отразится на времени и укажет причину и новые сроки.
4. Адекватный разработчик, кроме своих задач, должен видеть цель всего дела и понимать, что жизнь во круг изменяется часто и с этим ничего не поделаешь, бывают и действительно срочные задачи.
5. Адекватный разработчик, сможет объяснить, почему используется именно эта технология. И на вопрос а вот мы тут прочитали что Х круче, внятно объяснить почему им это не поможет. Технологии очень быстро развиваются, и руководство как ни странно общается и с другими людьми. И их интересует так же почему конкуренты используют Х и у них все хорошо, а мы используем У и у нас все плохо, может стоить потратить немного денег на закупку Х?
Дело осталось за малым. Собрать команду адекватных людей, которые вместо того чтобы выносить друг друг мозг взаимными придирками, соплями и понтами, будут делать одно общее дело…
Да, установка линукса на рабочую машину свела на нет часть возможных дополнительных задач :]
Я программист все-таки, а не мастер на все руки(хотя умею не только программировать, надо сказать:])
Я программист все-таки, а не мастер на все руки(хотя умею не только программировать, надо сказать:])
Читаю комменты, и как обычно основной тренд — «хороший программист/менеджер/директор никогда так не будет делать».
Проснитесь, мы с вами живем в реальном мире. Нас не окружают сплошь компетентные и мудрые люди, скорее наоборот! Учитесь жить в непростых условиях.
Проснитесь, мы с вами живем в реальном мире. Нас не окружают сплошь компетентные и мудрые люди, скорее наоборот! Учитесь жить в непростых условиях.
Кнопочка, рассылка и пр. работают как и во всех разделах ХХХХ
Раздражает, когда приходится «подчищать хвосты» за коллегами. Выглядит примерно так — «скорее, у нас завтра релиз, тестеры нашли баг, что граната взрывается в руках и уровень не пройти». На возражение что этот баг в сто раз быстрее исправит человек, который его и создал, заявляется что человек этот в отпуске / ушёл в декрет / уволился и т.д. И начинается копание в чужом коде, когда кол-во wtf в минуту зашкаливает.
Раздражает непонимание менеджерами сложности проблемы. Если взять для примера предыдущий абзац, то оказывается, что по-хорошему надо считать время анимации замаха, грузить из конфигов задержку до взрыва и т.д. что занимает время. «Нет, надо скорее, это же наверняка всего пару цифр поменять». Заканчивается зачастую тем, что ставится ещё один костыль.
Раздражает непонимание менеджерами сложности проблемы. Если взять для примера предыдущий абзац, то оказывается, что по-хорошему надо считать время анимации замаха, грузить из конфигов задержку до взрыва и т.д. что занимает время. «Нет, надо скорее, это же наверняка всего пару цифр поменять». Заканчивается зачастую тем, что ставится ещё один костыль.
показал коллегам по цеху — в ответ выдали картинку с расширенной версией 
>1. А сколько займет сделать этот раздел (дается ТЗ из одной строки)?
В большинстве своем это означает придумать решение какой-то проблемы и оценить его по срокам. На придумывание/оценку/согласование решения нужно время (1 час/день/неделя), а дальше видно будет. Чем опытнее программист и чем стандартнее проблема, тем быстрее он может выдать какое-то примерное решение и сказать вилку сроков реализации.
>2. Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя! (моют мозг по сроку из пункта 1)
п1, не обещать точных сроков, обещать подумать как это сделать.
В большинстве своем это означает придумать решение какой-то проблемы и оценить его по срокам. На придумывание/оценку/согласование решения нужно время (1 час/день/неделя), а дальше видно будет. Чем опытнее программист и чем стандартнее проблема, тем быстрее он может выдать какое-то примерное решение и сказать вилку сроков реализации.
>2. Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя! (моют мозг по сроку из пункта 1)
п1, не обещать точных сроков, обещать подумать как это сделать.
1. А сколько займет сделать этот раздел (дается ТЗ из одной строки)?
Как правило, отвлекают от работы вопросом, сбивают с потока. Просят назвать срок, когда неизвестна ни задача, ни требования, только одно предложение. И так настойчиво, что, чтобы отвалили, называешь прикидочный срок.
В тот момент, когда вы назвали срок, в котором совсем не уверены — вы проиграли, взяли ответственность на себя. Менеджер — это не царь и бог, вы имеете право сказать ему «не знаю». Менеджер имеет право сколько угодно спрашивать о чём угодно.
Вы совершили ошибку, а вините в ситуации только менеджера.
Как правило, отвлекают от работы вопросом, сбивают с потока. Просят назвать срок, когда неизвестна ни задача, ни требования, только одно предложение. И так настойчиво, что, чтобы отвалили, называешь прикидочный срок.
В тот момент, когда вы назвали срок, в котором совсем не уверены — вы проиграли, взяли ответственность на себя. Менеджер — это не царь и бог, вы имеете право сказать ему «не знаю». Менеджер имеет право сколько угодно спрашивать о чём угодно.
Вы совершили ошибку, а вините в ситуации только менеджера.
2. … Менеджеру: Постарайтесь давать точное ТЗ и бить задачу на простые кусочки, в чем программист с удовольствием поможет (если хорошо попросить). Тогда можно будет более точно управлять сроками.
Как только менеджер (а не вы) начнёт «бить задачу на простые кусочки» он возьмёт на себя ответственность архитектора или тимлида. И вообще, вы же только что писали, что «программист строит у себя в голове модель будущей системы» — программист, а не менеджер!
Есть стандартный подход user stories + technical tasks, где заказчик, product owner, менеджер формулируют одну возможность системы, которую нужно получить, а уже разработчики разбивают её на технические задачи трудоёмкостью не более 4-х часов.
Как только менеджер (а не вы) начнёт «бить задачу на простые кусочки» он возьмёт на себя ответственность архитектора или тимлида. И вообще, вы же только что писали, что «программист строит у себя в голове модель будущей системы» — программист, а не менеджер!
Есть стандартный подход user stories + technical tasks, где заказчик, product owner, менеджер формулируют одну возможность системы, которую нужно получить, а уже разработчики разбивают её на технические задачи трудоёмкостью не более 4-х часов.
5. Сверстай по-быстрому это, пожалуйста, и лучше на extJS.
Во-первых, я не люблю верстку. Это особая работа, и ее должны делать профессионалы, которые обладают усидчивостью. Вообще, я уважаю верстальщиков — уметь сверстать так, чтобы везде было одинаково, это мастерство и очень круто. Просто руки к этому не лежат.
А я не люблю по телефону разговаривать и баги править. Но могу. Вам за работу деньги платят, причём когда вам платят за вашу хреновую (например) вёрстку, то вам ещё и сильно переплачивают. Вас же не картриджи в принтерах менять гоняют?
Если вы умеете верстать, то вполне может статься, что менеджера и заказчика вполне устроит качество на троечку, полученное с вашей помощью сегодня, а не блестящий и красивый код с помощью профверстальщика через неделю и ещё 500 долларов, потраченных на его поиск, мотивацию, договорённости, постановку задачи, контроль и т.д.
Блестящий и красивый код важен только вам.
Но во-вторых, как программиста, меня всегда бесит, когда менеджер лезет в мою среду и пытается мне доказать, что я не прав, что верстать надо не на дивах и не верстальщику, а мне и на extJS, потому что вчера он прочитал об этом на Хабре, поняв только 10% слов и запомнив название JS библиотеки.
Если конкретно на extJS не умеете — так и скажите. Скажите, что для освоения extJS вам потребуется ещё 20 часов.
Во-первых, я не люблю верстку. Это особая работа, и ее должны делать профессионалы, которые обладают усидчивостью. Вообще, я уважаю верстальщиков — уметь сверстать так, чтобы везде было одинаково, это мастерство и очень круто. Просто руки к этому не лежат.
А я не люблю по телефону разговаривать и баги править. Но могу. Вам за работу деньги платят, причём когда вам платят за вашу хреновую (например) вёрстку, то вам ещё и сильно переплачивают. Вас же не картриджи в принтерах менять гоняют?
Если вы умеете верстать, то вполне может статься, что менеджера и заказчика вполне устроит качество на троечку, полученное с вашей помощью сегодня, а не блестящий и красивый код с помощью профверстальщика через неделю и ещё 500 долларов, потраченных на его поиск, мотивацию, договорённости, постановку задачи, контроль и т.д.
Блестящий и красивый код важен только вам.
Но во-вторых, как программиста, меня всегда бесит, когда менеджер лезет в мою среду и пытается мне доказать, что я не прав, что верстать надо не на дивах и не верстальщику, а мне и на extJS, потому что вчера он прочитал об этом на Хабре, поняв только 10% слов и запомнив название JS библиотеки.
Если конкретно на extJS не умеете — так и скажите. Скажите, что для освоения extJS вам потребуется ещё 20 часов.
По поводу первого пункта — извините но у вас ответ как у солдата-срочника, который копает от забора и до обеда, а что в итоге получится дорога или канава — его не очень интересует. Обычно когда дают ТЗ из одного предложения — профессионал спрашивает а зачем это делать. А дальше идут попытки конкретизировать что надо сделать. Определяются приоритетные фичи, разбиваются на задачи и дается эстимейт. В таком случае хорошо и вам и менеджеру. Вы четко понимаете что и зачем нужно сделать, а менеджер знает что и когда будет сделано.
Upd.: в статье описаны, по сути, антипаттерны взаимодействия менеджера и программиста. Конечно, адекватный менеджер так себя не ведет, а адекватный программист рано или поздно встретит хорошего менеджера. Я в это верю. :)
Т.е. менеджер в этих антипаттернах виноват тем, что неправильно себя ведёт.
А программист виноват только тем, что попал в компанию с таким менеджером.
Отличная демонстрация внешней референции и зависимой, рабской личной позиции.
Т.е. менеджер в этих антипаттернах виноват тем, что неправильно себя ведёт.
А программист виноват только тем, что попал в компанию с таким менеджером.
Отличная демонстрация внешней референции и зависимой, рабской личной позиции.
Какая то холиварная тема уже становится. Мне кажется это вечный конфликт между программистом и менеджером, да в каких то случаях есть равновесие, когда хороший и понимающий менеджер и такой же программист, однако как тут писали в жизни как раз 80% случаев это война с короткими перемириями.
Оставшиеся 20% просто хорошо над этим вопросом поработали и получили на выходе хороший результат. Я так полагаю, что у таких компаний все в порядке с делами, с клиентами и с процессами и, соответственно, с бизнесом в целом.
Оставшиеся 20% просто хорошо над этим вопросом поработали и получили на выходе хороший результат. Я так полагаю, что у таких компаний все в порядке с делами, с клиентами и с процессами и, соответственно, с бизнесом в целом.
Менеджеру: программист — это программист, не нужно давать ему лишней работы, к примеру, нарезать макет в фотошопе (у многих, как у меня, вообще стоит Линукс)
А у меня дома ключ на 18, а ключа на 24 нет, идите к Васе.
Офигительный аргумент — что у вас там СТОИТ.
А у меня дома ключ на 18, а ключа на 24 нет, идите к Васе.
Офигительный аргумент — что у вас там СТОИТ.
Ужасно выбешивает когда отсуствует технический директор, т.е. по сути весь проект держится на паре прогеров. В итоге очень часто случаются такие ужасно раздражающие ситуации когда тебя сначала просят что то сделать, ты это делаешь, а потом говорят что-то типа, мы передумали, давайте это уберём и сделаем вот так вот, потом в итоге возвращаемся к исходному варианту.
Проблема программистов (и, кстати, далеко не только их), что они относятся к начальству как к к чему-то неизменному. На самом деле менеджмент работает в обе стороны: как программист реагирует на работу начальства, так оно и работает. Если беспрекословно делать все что скажут, и отводить весь негатив в /dev/null — оно будет делать так, как проще ему, а все косяки, которые потом выйдут, повесят на вас. Конечно, итогом может стать и тупо потеря хорошего специалиста, но тут уж сложно сказать, что кто-то выиграл, потому что на новом месте, если программист не изменит своего отношения, все скатится к тому же процессу.
Решение в том, чтобы отстаивать свою позицию как профессионала, с определенными требованиями к условиям труда, разумеется, обосновывая свою позицию разумными доводами. Ну а если окажется, что начальник не настроен что-то менять и относится к вам как к рабочей силе, выводы делайте сами. Просто не нужно делать эти выводы до того, как вы попытаетесь что-то изменить.
С некоторыми корректировками можно использовать и в семейной жизни )
Решение в том, чтобы отстаивать свою позицию как профессионала, с определенными требованиями к условиям труда, разумеется, обосновывая свою позицию разумными доводами. Ну а если окажется, что начальник не настроен что-то менять и относится к вам как к рабочей силе, выводы делайте сами. Просто не нужно делать эти выводы до того, как вы попытаетесь что-то изменить.
С некоторыми корректировками можно использовать и в семейной жизни )
Перечитал коммент и навеяло сравнение: представьте, что пишите программу, а там где-то ошибка. Но компилятор ничего вам не говорит, программа глючит по непонятным причинам, в логах все красиво, дебаггера, увы, не существует. А потом компилятор берет и самоудаляется. И вам придется искать новый компилятор, а то и изучать новый язык. Наверное, как-то так выглядит работа менеджера.
Добавил бы в топ:
«Составьте почасовой список того, что делали в прошлом месяце (на прошлой неделе)».
То есть они как бы говорят мне, что не знают, что я вообще делал все это время.
То есть фактически обвиняют в безделье и лжи.
«Составьте почасовой список того, что делали в прошлом месяце (на прошлой неделе)».
То есть они как бы говорят мне, что не знают, что я вообще делал все это время.
То есть фактически обвиняют в безделье и лжи.
В статье заинтересовала структура подразделения
На сколько я понял программист на прямую выполняет задачи какого-то менеджера, который даже не представляет технологии реализации своей проблемы.
Это самая тяжела форма взаимодействия, тогда программист становится многостаночником (проектировщик, дизайнер, программист, верстальщик, тестировщик, консультант и т.д.)
На сколько я понял программист на прямую выполняет задачи какого-то менеджера, который даже не представляет технологии реализации своей проблемы.
Это самая тяжела форма взаимодействия, тогда программист становится многостаночником (проектировщик, дизайнер, программист, верстальщик, тестировщик, консультант и т.д.)
А теперь подумайте, какая нужна квалификация, чтобы работать в условиях, когда уже есть квалифицированный проектировщик, дизайнер, программист, верстальщик, тестировщик, консультанты по предметной области и т.д… Человек делает шаг влево, а ему выволочку, «зачем полез дизайн трогать? Есть отработанная процедура согласования изменения в дизайне с проектировщиком, который сам назначит задачи на дизайнера и верстальщика». Он пишет вспомогательную утилиту — а ему в ответ «у нас есть coding guide специально для вспомогательных утилит, три главы в третьем томе и глава в пятом». Он ставит пробел после знака '$', а ему в ответ консультант в истерике «я 100500 раз говорил, то между валютой и суммой пробел ставиться не должен, и этому посвящена глава в пятнадцатом томе вопросов и ответов между отделом разработки и отделом консультаций».
Не поверите, последние 5 лет мечтаю о такой работе. квалификация — узкая, ответственность — минимальная, просто сказка.
Кстати, реально такую систему могут создать только бывшие военные. Современный мальчики-менеджеры не в состоянии добиться такого результата, потому что тут нужна воля, решительность, трудолюбие.
Но это уже совсем другая тема
А то о чем вы говорите — это бардак, если есть в ТЗ пункт о местоположении $, то и вопросов нет, все остальное — личное разгильдяйство сотрудников. Если каждая личность начнет высказывать свое «профессиональное» мнение, то это в любом случае приведет к краху проекта.
PS роль руководителей можно много и долго оспаривать, но попробуйте проехать на мотоцикле(одиночке) в качестве пассажира. Если вы не «отдадитесь» водителю, то погибнете оба.
Если нет такого опыта, то даже не спорьте, просто попробуйте, НО ТОЛЬКО НА МАЛЫХ СКОРОСТЯХ и в ХОРОШЕМ ШЛЕМЕ. И только после этого вы поймете, что из двух работников, один должен быть руководителем
Кстати, реально такую систему могут создать только бывшие военные. Современный мальчики-менеджеры не в состоянии добиться такого результата, потому что тут нужна воля, решительность, трудолюбие.
Но это уже совсем другая тема
А то о чем вы говорите — это бардак, если есть в ТЗ пункт о местоположении $, то и вопросов нет, все остальное — личное разгильдяйство сотрудников. Если каждая личность начнет высказывать свое «профессиональное» мнение, то это в любом случае приведет к краху проекта.
PS роль руководителей можно много и долго оспаривать, но попробуйте проехать на мотоцикле(одиночке) в качестве пассажира. Если вы не «отдадитесь» водителю, то погибнете оба.
Если нет такого опыта, то даже не спорьте, просто попробуйте, НО ТОЛЬКО НА МАЛЫХ СКОРОСТЯХ и в ХОРОШЕМ ШЛЕМЕ. И только после этого вы поймете, что из двух работников, один должен быть руководителем
Вы верите в ТЗ, в котором описано всё? Но очевидно, что если в ТЗ описана вся программа, то дальше вопрос исключительно и только в написании компилятора из ТЗ в машинный код. (А как вы ТЗ отлаживать собираетесь?).
Разумеется, в ТЗ описывается не всё. И идеальное ТЗ не должно описывать всё, а должно описывать только те вещи, которые важны для заказчика.
А вот ваше бухтение насчёт «современных мальчиков-менеджеров» мне лично не понятно. Старые пердуны (видимо, как омоним к «современным мальчикам-менеджерам») даже близко не работали в условиях современного объёма кода.
Собственно, что там говорить — общий объём исходного текста у нас в продакте — примерно 7 гигабайт. Пакованных и без учёта версий в гите.
Разумеется, в ТЗ описывается не всё. И идеальное ТЗ не должно описывать всё, а должно описывать только те вещи, которые важны для заказчика.
А вот ваше бухтение насчёт «современных мальчиков-менеджеров» мне лично не понятно. Старые пердуны (видимо, как омоним к «современным мальчикам-менеджерам») даже близко не работали в условиях современного объёма кода.
Собственно, что там говорить — общий объём исходного текста у нас в продакте — примерно 7 гигабайт. Пакованных и без учёта версий в гите.
«я 100500 раз говорил, то между валютой и суммой пробел ставиться не должен, и этому посвящена глава в пятнадцатом томе вопросов и ответов между отделом разработки и отделом консультаций»
Это ваши слова? Значит разговор был, и он решен однозначно. Так зачем тогда ставят пробел? Либо не читают документацию, либо саботируют.
PS Почему я заговорил о военных — Все воинские Уставы написаны «кровью»! Для программиста тех. документация как устав, упустил слово, в лучшем случае рассчитаешься модулем, в худшем — структурой БД.
Сколько страниц в уставе, который написан кровью? Просто для понимания, одна-единственная мелкая тема — ipv6, состоит из всего лишь из 43 актуальных RFC (и ещё примерно сотни obsolete, которые ещё надо уметь отличать от актуальных), в которых всего-навсего 144 тысячи строк (422 тысяч слов). Просто для понимания масштаба, в войне и мире всего 180 тысяч слов.
А ведь это лишь мелкая часть жизни, всего лишь и только ipv6. Есть ещё несколько тысяч RFC, которые касаются всего — от OAuth до XML и MIME. А ведь жизнь программистов на RFC не заканчивается.
Другими словами, попытка сравнить уютненький и коротенький воинский устав с документацией к ПО, это всё равно, что сравнить проектную документацию к мосту через канаву из трёх брёвен и досок с документацией к 10-полосному мосту километров в 30 длинной.
И разница между «сделал не по уставу» и «нарушил RFC 3445 страница 140, где сказано, что если у заголовка преассоциации был указан loose в полиси вторичного удостоверяющего центра, то транзитивный атрибут следует применять только если не определён собственный» именно такая. Одно написано кровью, а другое — гиками. В неописуемом объёме.
А ведь это лишь мелкая часть жизни, всего лишь и только ipv6. Есть ещё несколько тысяч RFC, которые касаются всего — от OAuth до XML и MIME. А ведь жизнь программистов на RFC не заканчивается.
Другими словами, попытка сравнить уютненький и коротенький воинский устав с документацией к ПО, это всё равно, что сравнить проектную документацию к мосту через канаву из трёх брёвен и досок с документацией к 10-полосному мосту километров в 30 длинной.
И разница между «сделал не по уставу» и «нарушил RFC 3445 страница 140, где сказано, что если у заголовка преассоциации был указан loose в полиси вторичного удостоверяющего центра, то транзитивный атрибут следует применять только если не определён собственный» именно такая. Одно написано кровью, а другое — гиками. В неописуемом объёме.
По поводу первого и второго — если ТЗ написано, расписано по issue, которые предварительно согласнованы с программистами, то вопрос «сколько story points» на этот issue — совершенно законный. А дальше вопрос простой: почему после окончания спринта невыполненные issue?
Иначе (хорошие) программисты начинают неограниченно увлекаться перфекционизмом кода. Иногда в местах, где это просто не нужно, иногда входя в противоречие с будущим проектов, иногда пропуская мелкую деталь, которая стопит всё остальное (вне зависимости от того, как всё остальное офигенно).
В этом и есть идея scrum.
Иначе (хорошие) программисты начинают неограниченно увлекаться перфекционизмом кода. Иногда в местах, где это просто не нужно, иногда входя в противоречие с будущим проектов, иногда пропуская мелкую деталь, которая стопит всё остальное (вне зависимости от того, как всё остальное офигенно).
В этом и есть идея scrum.
А вообще-то если манагер слишком достает — он посылается на куй.
Вменяемого разработчика найти сложно, а манагеров — сегодня выпни — завтра очередь придет претендентов на теплое место бездельничать…
Вменяемого разработчика найти сложно, а манагеров — сегодня выпни — завтра очередь придет претендентов на теплое место бездельничать…
Да да :), именно поэтому ЗП хороших манагеров на порядок выше хороших специалистов
В большей части компаний в России (правда, беру только малый-средний бизнес) этому есть две причины, как правило:
1) Работу манагера легко можно оценить. Работу специалиста (читай инженера, технаря или как угодно) оценить сложнее. К примеру, манагер за 1 месяц заключил договоров на 1 млн рублей, а программист за это время написал один модуль для разрабатываемой платформы. Кто «принёс прибыль компании» с точки зрения управленца? Кому нужно заплатить за это?
2) Манагер сидит на процентах, технарь — на окладе. Далее — см выше (манагер заключил договоров на 1млн рублей — ему определённое количество процентов)
В крупных компаниях, безусловно, просчитываются показатели эффективности конкретного сотрудника, в таком случае данные варианты могут иметь, а могут не иметь места.
Надеюсь, тут я особо не попутал термины «sales», «PM», «cleaning manager» и прочие.
1) Работу манагера легко можно оценить. Работу специалиста (читай инженера, технаря или как угодно) оценить сложнее. К примеру, манагер за 1 месяц заключил договоров на 1 млн рублей, а программист за это время написал один модуль для разрабатываемой платформы. Кто «принёс прибыль компании» с точки зрения управленца? Кому нужно заплатить за это?
2) Манагер сидит на процентах, технарь — на окладе. Далее — см выше (манагер заключил договоров на 1млн рублей — ему определённое количество процентов)
В крупных компаниях, безусловно, просчитываются показатели эффективности конкретного сотрудника, в таком случае данные варианты могут иметь, а могут не иметь места.
Надеюсь, тут я особо не попутал термины «sales», «PM», «cleaning manager» и прочие.
Ну вы конечно сравнили Гоголя с Гегелем. Программисты и менеджеры по продажам, как правило абсолютно не совместимые люди, ни профессионально, ни психологически. Инструмент программиста — интеллект, менеджера по продажам — эмоции. И измерять их одной линейкой не логично
Для PM это также во многом справедливо, тем не менее. И да, Вы говорили о ЗП, а не об интеллекте и иже с ними.
К примеру, я знал несколько совершенно бездарных PM, которые выпускали на рынок совершенно сырые продукты, пытаясь скинуть всю вину на «админов, у которых всё падает», притом не один человек предупреждал даже высшее руководство: «ЭТО нельзя продавать, ибо оно будет падать»
К примеру, я знал несколько совершенно бездарных PM, которые выпускали на рынок совершенно сырые продукты, пытаясь скинуть всю вину на «админов, у которых всё падает», притом не один человек предупреждал даже высшее руководство: «ЭТО нельзя продавать, ибо оно будет падать»
Cord, я не пойму, так вы менеджер или программист? :)
В прошлом программист и об этом пост, сейчас менеджер проектов, но иногда программлю:)
И что вы даете девам говнокодить всю неделю кроме пятницы-рефакторницы? :)
Имхо вы слишком рано оставили чернорабочий труд, не прочуяли что от вас хотел менеджер и уже лезете с своимии манифестами. Отвлекать дева не стоит, но и не отвлекать глупо — нужно сотрудничество. Тем более дев склонен писать то что от него не требовали, днями напролет. Рефакторинг не выбивать надо, а делать — в те сроки которые озвучили всю задачу. Верстать как правильно указали — если надо, то медленно, коряво, но надо. Не хочется — так и скажи — не хочу. Менеджеру виднее стоит ли аутсорсить, нанимать или обойтись. А тот дев который не мечтает разбираться во всем — ну станет таким же менеджером, способным лишь доверять и подгонять комманду. И вообщ, прозрачнее надо быть и коммуникативнее, и раздражение перейдет в обучение. В том числе и управлению такими как сам.
Имхо вы слишком рано оставили чернорабочий труд, не прочуяли что от вас хотел менеджер и уже лезете с своимии манифестами. Отвлекать дева не стоит, но и не отвлекать глупо — нужно сотрудничество. Тем более дев склонен писать то что от него не требовали, днями напролет. Рефакторинг не выбивать надо, а делать — в те сроки которые озвучили всю задачу. Верстать как правильно указали — если надо, то медленно, коряво, но надо. Не хочется — так и скажи — не хочу. Менеджеру виднее стоит ли аутсорсить, нанимать или обойтись. А тот дев который не мечтает разбираться во всем — ну станет таким же менеджером, способным лишь доверять и подгонять комманду. И вообщ, прозрачнее надо быть и коммуникативнее, и раздражение перейдет в обучение. В том числе и управлению такими как сам.
Пардон за запятые, планшет.
Вкратце хотел сказать — как программист не употребляйте в разговоре с заказчиком/менеджером, слова такого «рефакторинг». Вы либо делаете *всё* что надо (сами называете срок) либо раздражайтесь дальше. От вас требуется делать качественно, а не только быстро. Оценивать соответственно.
Вкратце хотел сказать — как программист не употребляйте в разговоре с заказчиком/менеджером, слова такого «рефакторинг». Вы либо делаете *всё* что надо (сами называете срок) либо раздражайтесь дальше. От вас требуется делать качественно, а не только быстро. Оценивать соответственно.
5 лет промышленного кодинга и 10 вообще — это достаточно.
А пост специально написан провокационным. Иначе, без конфликта, как говорят классики, читать неинтересно.
А пост специально написан провокационным. Иначе, без конфликта, как говорят классики, читать неинтересно.
«А сколько займет сделать этот раздел ...?»
А если сказать кодеру, что это юзерстори?
А если сказать кодеру, что это юзерстори?
Менеджер:
Я:
Менеджер (услышал только первые слова):
Я:
О, ты свободен, ничего не делаешь? Тогда вот возми, пересчитай листочки в этой пачке прямо сейчас.
Я:
Я очень занят, у меня проект висит, который Вы же мне и выдали и я вот подошёл, чтобы уточнить детали по нему.
Менеджер (услышал только первые слова):
Так чего ты тут ходишь просто так?! Иди найди кого-нибудь, кто пересчитает листочки или пересчитай их сам. И вообще, почему ты проект мне ещё не сдал??
Я:
*утробный рррр*!!!
Бесит фраза «Ну ты ведь профессионал»
что-то много стало на хабре статей несчастных программистов…
мне вот всегда интересно было, люди в подобные моменты вообще задаются вопросом откуда берутся деньги на их ЗП?
мне вот всегда интересно было, люди в подобные моменты вообще задаются вопросом откуда берутся деньги на их ЗП?
>>задаются вопросом откуда берутся деньги на их ЗП?
Зачем? Мы же программисты ;) Мы используем инкапсуляцию на всю катушку. То что нам не положено знать, то мы и не знаем ) Откуда берутся деньги это ответственность класса Manager, а не Developer :)
Шутка. Но суть в том, что каждый должен заниматься своим делом и знать ровно то что его касается до тех пор пока он не решил сменить сферу деятельности
Зачем? Мы же программисты ;) Мы используем инкапсуляцию на всю катушку. То что нам не положено знать, то мы и не знаем ) Откуда берутся деньги это ответственность класса Manager, а не Developer :)
Шутка. Но суть в том, что каждый должен заниматься своим делом и знать ровно то что его касается до тех пор пока он не решил сменить сферу деятельности
в таком случае, наверное, глупо называть раздражающими запросы по поводу стоимости задачи от класса Manager? на то он и объект класса Manager, что стремится измерить все в часах-днях(читай деньгах).
ответ на ремарку не шутку: Да, должен, но он так же должен понимать в какого рода конторе он работает:
1. например гос учреждение, пишут что-то для себя, деньги получают независимо от результата.
2. контора продающая софт, который пишет(Parallel, Kaspersky, Acronis).
глупо приходить в контору номер два и раздражаться от того, что с вас спрашивают сроки завершения задачи. Или что требования порой меняются(такое бывает, это жизнь). Наверное, вполне очевидно какая будет обстановка в конторе номер 1 и номер 2? и может разумно устроиться в контору номер 1 и жить себе спокойно? так что, как ни крути, но если объект класса Developer, не способен взаимодействовать с объектом класса Manager(в том числе выдавать сроки и следовать им), то в этой связке один из объектов надо менять.
п.с. вторая подобная статья на хабре за последнее время, но вроде взрослые люди пишут и это удивительно. Вообще лирическое, но мне кажется есть такая опасность для девелопера утратить связь с реальным миром и сильно переоценить себя. Некая локальная звездная болезнь. Не подумайте только, что я такой гуру высокомерный, но случаи правда были и карьера людей слегка ломалась в такие моменты…
ответ на ремарку не шутку: Да, должен, но он так же должен понимать в какого рода конторе он работает:
1. например гос учреждение, пишут что-то для себя, деньги получают независимо от результата.
2. контора продающая софт, который пишет(Parallel, Kaspersky, Acronis).
глупо приходить в контору номер два и раздражаться от того, что с вас спрашивают сроки завершения задачи. Или что требования порой меняются(такое бывает, это жизнь). Наверное, вполне очевидно какая будет обстановка в конторе номер 1 и номер 2? и может разумно устроиться в контору номер 1 и жить себе спокойно? так что, как ни крути, но если объект класса Developer, не способен взаимодействовать с объектом класса Manager(в том числе выдавать сроки и следовать им), то в этой связке один из объектов надо менять.
п.с. вторая подобная статья на хабре за последнее время, но вроде взрослые люди пишут и это удивительно. Вообще лирическое, но мне кажется есть такая опасность для девелопера утратить связь с реальным миром и сильно переоценить себя. Некая локальная звездная болезнь. Не подумайте только, что я такой гуру высокомерный, но случаи правда были и карьера людей слегка ломалась в такие моменты…
Наличие таких статей говорит об общем низком уровне менеджмента
Как там 30 лет назад в peopleware писал Демарко о травле команд, так и сейчас все актуально. Безумно отвлекающая людей эджайл-болтовня, управленцы-нетехнари, ни одной строки не написавшие и даже эмпатией для понимания программиста не обладающие, управленцы-финансисты, управленцы с подходом к программистам как к заводским работягам с кипиай и тд, дефицит проджектов вообще…
А почему профессионал может ожидать от менеджера и бизнеса плясок вокруг него, потому что он работу сменит за два клика, а компания потратит несколько тысяч (иногда десятков) долларов на замену профессионала.
Как там 30 лет назад в peopleware писал Демарко о травле команд, так и сейчас все актуально. Безумно отвлекающая людей эджайл-болтовня, управленцы-нетехнари, ни одной строки не написавшие и даже эмпатией для понимания программиста не обладающие, управленцы-финансисты, управленцы с подходом к программистам как к заводским работягам с кипиай и тд, дефицит проджектов вообще…
А почему профессионал может ожидать от менеджера и бизнеса плясок вокруг него, потому что он работу сменит за два клика, а компания потратит несколько тысяч (иногда десятков) долларов на замену профессионала.
вам стоит устроиться в два клика в организацию первого типа, там эджайлом вас не побеспокоят и вы сможете реализоваться как «профессионал» в бесконечном ватерфоле…
Когда пришел в команду, где сейчас работаю, в которой применяется Agile у меня мнение было на уровне «Клуб анонимных алкоголиков». Казалось что все так и жалуются «Я вчера выпил, очень плохо, надо бы завязывать. Сегодня постараюсь не пить». Все оказалось не так печально как мне казалось в первые моменты. Недостатки есть, но и плюсов не мало!
1) Ты работаешь!
Всеми модная тема «прокрастинация». В Agile она глохнет! Все потому что завтра нужно будет ответить на вопрос «Какой результат ты получил?». Если сегодня ты ничего не сделал, то что ответишь завтра? Хорошо, 5 дней подряд болели зубки и ребенка твоего, но не 2 недели же подряд!!!
2) Ты не остаешься с проблемой один на один
Если вдруг у тебя возникла проблема, то через 2-3 дня это будет видно. Тебя так и спросят «Что-то ты уже 3 день подряд возишься. В чем конкретно трудность?». Это раньше можно было биться головой об стену и пойти у своей гордыни на поводу «Я? И не решу? Да не в жизнь!». Нет. При Agile тебе такого не дадут, через 3 дня тебя пнут в нужный мануал, подойдет коллега или еще что-то произойдет, но проблема исчезнет!
3) Ты всегда занимаешься тем что нужно
Если кто-то сказал «Да что-то ты весь год херней страдаешь». При Agile ты всегда можешь сказать «Ребят. Да ну? И ты весь год молчали?». Это как бы дает возможность пристыдить тех кто пытается на тебя наехать. Ведь если они смолчали и не указали на проблему, то они такие же саботажники как и ты!
1) Ты работаешь!
Всеми модная тема «прокрастинация». В Agile она глохнет! Все потому что завтра нужно будет ответить на вопрос «Какой результат ты получил?». Если сегодня ты ничего не сделал, то что ответишь завтра? Хорошо, 5 дней подряд болели зубки и ребенка твоего, но не 2 недели же подряд!!!
2) Ты не остаешься с проблемой один на один
Если вдруг у тебя возникла проблема, то через 2-3 дня это будет видно. Тебя так и спросят «Что-то ты уже 3 день подряд возишься. В чем конкретно трудность?». Это раньше можно было биться головой об стену и пойти у своей гордыни на поводу «Я? И не решу? Да не в жизнь!». Нет. При Agile тебе такого не дадут, через 3 дня тебя пнут в нужный мануал, подойдет коллега или еще что-то произойдет, но проблема исчезнет!
3) Ты всегда занимаешься тем что нужно
Если кто-то сказал «Да что-то ты весь год херней страдаешь». При Agile ты всегда можешь сказать «Ребят. Да ну? И ты весь год молчали?». Это как бы дает возможность пристыдить тех кто пытается на тебя наехать. Ведь если они смолчали и не указали на проблему, то они такие же саботажники как и ты!
>>на то он и объект класса Manager, что стремится измерить все в часах-днях(читай деньгах)
Как говорит ув. Джоэл Спольски, «абстракции протекают».
Надо учитывать, что мы, разработчики, менеджеры — все люди. В наших головах как всегда слишком много всего, и не все что ЭТО сидящее в наших головах относится к работе. У меня, слишком много примеров, когда менеджеры «лижут» мягкое место вышестоящему менеджеру чтобы получить какие-то свои плюшки.
Может я излишне старомоден, отец всегда учил: «Ты чего на других ровняешься? Ты на себя смотри! Пусть твое дело за тебя говорит». Не знаю насколько это окажется правильным, когда я буду думать о прожитой жизни скажем лет в 80, но пока это та жизненная мудрость, которая многое поясняет в этой жизни. И именно исходя из этой мысли и рассуждаю, что каждый сотрудник компании должен заниматься тем для чего его наняли!
Вот вы говорите:
>>но и взаигмодействовать с объектом класса Manager(в том числе выдавать сроки и следовать им)
Я когда-то в далеком 2007-м году в декабре побывал в Luxoft. Там был «халявный» доклад от Асхата Аразбаева про Agile. Не знаю кто именно, возможно сам Асхат, не буду утверждать, но высказал мысль: «Хороший руководитель тот, которого не видно и не слышно, а процесс между тем идет и очень хорошо идет».
Я к тому что «взаимодействие» должен выстраивать Менеджер, а не Разработчик. Коммуникационный навык для Менеджера является первостепенным. Каким бы не был у него разработчик нелюдимым, именно ему Менеджеру надо первому налаживать контакт. Если от разработчика нету внятных сроков или отчетов, значит руководитель не донес, не убедился что разработчик понял суть рабочего процесса. Случаи конечно разные бывают, не буду впадать в крайность, но думаю то что хочу высказать и до нести уже ясно.
Как говорит ув. Джоэл Спольски, «абстракции протекают».
Надо учитывать, что мы, разработчики, менеджеры — все люди. В наших головах как всегда слишком много всего, и не все что ЭТО сидящее в наших головах относится к работе. У меня, слишком много примеров, когда менеджеры «лижут» мягкое место вышестоящему менеджеру чтобы получить какие-то свои плюшки.
Может я излишне старомоден, отец всегда учил: «Ты чего на других ровняешься? Ты на себя смотри! Пусть твое дело за тебя говорит». Не знаю насколько это окажется правильным, когда я буду думать о прожитой жизни скажем лет в 80, но пока это та жизненная мудрость, которая многое поясняет в этой жизни. И именно исходя из этой мысли и рассуждаю, что каждый сотрудник компании должен заниматься тем для чего его наняли!
Вот вы говорите:
>>но и взаигмодействовать с объектом класса Manager(в том числе выдавать сроки и следовать им)
Я когда-то в далеком 2007-м году в декабре побывал в Luxoft. Там был «халявный» доклад от Асхата Аразбаева про Agile. Не знаю кто именно, возможно сам Асхат, не буду утверждать, но высказал мысль: «Хороший руководитель тот, которого не видно и не слышно, а процесс между тем идет и очень хорошо идет».
Я к тому что «взаимодействие» должен выстраивать Менеджер, а не Разработчик. Коммуникационный навык для Менеджера является первостепенным. Каким бы не был у него разработчик нелюдимым, именно ему Менеджеру надо первому налаживать контакт. Если от разработчика нету внятных сроков или отчетов, значит руководитель не донес, не убедился что разработчик понял суть рабочего процесса. Случаи конечно разные бывают, не буду впадать в крайность, но думаю то что хочу высказать и до нести уже ясно.
отчасти соглашусь. но замечу, что у менеджера не цель выстраивать общение с разработчиком, это лишь способ достичь результата. отсюда и другие способы достичь оного, например заменить уж очень замкнутый объект класса Девелопер. Случай был, девелопер не хотел проходить ревью перед коммитом в чужую библиотеку и поставил условие, что мол отменяйте для меня ревью, а не то уволюсь. И был уволен. сейчас назад просится, но вакансии уже нет. Так что парни, при всем уважении, не зарывайтесь, компромисс, это когда он с обоих сторон.
>>не хотел проходить ревью перед коммитом в чужую библиотеку
Опять же это проблема руководителя. Можно было до нести важность ревью, почему-то уверен что можно. Руководителю надо было разобраться что движет человеком в жизне, какие у него стремления, что занимает его голову и потом показав ему то что он Разработчик может получить из-за ревью, какой опыт, какие знания или какие другие плюшки. А может человек банально боится того, что его застебают за что-нибудь. Всяких «может» слишком много! Выявлять эти «может» и есть задача руководителя.
Вспомним детей?! Они даже играть не умеют! Это мы Взрослые учим их играть с машинками, с куклами, с кубиками и др. вещами.
Я знаю парня, который может из команды бездарей может сделать реальный успешный проект! Именно смотря на него понимаю, что все зависит от того хочет ли человек руководить или ему «реально влом» заниматься тем что делает из человека хорошим руководителем.
Опять же это проблема руководителя. Можно было до нести важность ревью, почему-то уверен что можно. Руководителю надо было разобраться что движет человеком в жизне, какие у него стремления, что занимает его голову и потом показав ему то что он Разработчик может получить из-за ревью, какой опыт, какие знания или какие другие плюшки. А может человек банально боится того, что его застебают за что-нибудь. Всяких «может» слишком много! Выявлять эти «может» и есть задача руководителя.
Вспомним детей?! Они даже играть не умеют! Это мы Взрослые учим их играть с машинками, с куклами, с кубиками и др. вещами.
Я знаю парня, который может из команды бездарей может сделать реальный успешный проект! Именно смотря на него понимаю, что все зависит от того хочет ли человек руководить или ему «реально влом» заниматься тем что делает из человека хорошим руководителем.
При всем уважении, вы несколько наивны, бывает, что люди не уговариваются…
Неужели вы думаете, что мы его молча отпустили и не пытались отговорить? Он у нас вообще лет 6 проработал, то есть мы его ценили и сейчас ценим. Так что давайте признаем все же, что вешать всех собак на манагера не справедливо и будем спать :) я в данном кейсе как манагер манагера не обвинял оного в том, что он упустил девелопера и, думаю, что поступил справедливо. Доброй ночи…
Неужели вы думаете, что мы его молча отпустили и не пытались отговорить? Он у нас вообще лет 6 проработал, то есть мы его ценили и сейчас ценим. Так что давайте признаем все же, что вешать всех собак на манагера не справедливо и будем спать :) я в данном кейсе как манагер манагера не обвинял оного в том, что он упустил девелопера и, думаю, что поступил справедливо. Доброй ночи…
Тогда не удивляйтесь, что менеджеры, в свою очередь, будут тоже «использовать инкапсуляцию на всю катушку» и класть на ваши рефакторинги, архитектуру и прочие «излишества. Должен быть здоровый компромисс. Оптимально, чтобы у менеджера был, хотя бы минимальный технический бекграунд. Программист, в свою очередь, должен „снисходить до простых смертных“ и общаться с другими участниками команды на их языке. Это не сложно, просто вопрос привычки.
— Вася, сколько времени это займет?
— Семен, смотри, у нас 2 пути. Можно наговнокодить за день чего-то. Кушать это ложкой будем потом еще 2 недели: это называется технический долг (мы берем время как-бы „взаймы“ — отдавать придется с процентами). Второй вариант. Есть одна штука в этой задаче, с которой я еще не работал, давай заведем задачу на ресерч на 4 часа, а потом я смогу дать более точную оценку. Думаю, что за 4-5 дней можно сделать все с шиком, блеском.
Если менеджер не конченный псих, то время на ресерч вам дадут.
— Вася, сколько времени это займет?
— Семен, смотри, у нас 2 пути. Можно наговнокодить за день чего-то. Кушать это ложкой будем потом еще 2 недели: это называется технический долг (мы берем время как-бы „взаймы“ — отдавать придется с процентами). Второй вариант. Есть одна штука в этой задаче, с которой я еще не работал, давай заведем задачу на ресерч на 4 часа, а потом я смогу дать более точную оценку. Думаю, что за 4-5 дней можно сделать все с шиком, блеском.
Если менеджер не конченный псих, то время на ресерч вам дадут.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Top 5 раздражающих моментов в работе программиста