На самом деле, мне, как заказчику, не выгодно раскрывать разработчикам мои методы тестирования при приёмке: с моей точки зрения возрастёт риск того, что они просто заточат продукт под прохождение именно этих тестов. Как заказчик я хочу указать фуцкциональность, а уж как я её собираюсь тестировать — это моё дело.
Про защиту команды — это замечательно. Согласен на сто процентов. Так и должно быть. Но вот про дамоклов меч я не понял. Всё же, что происходит, когда сроки нарушаются и проект начинает запаздывать?
И про поиски причины неудачи на стороне мне тоже не ясно. А если всё же причина кроется внутри команды, тогда что?
Сравнение программирования со строительством не так уж и ново, и в нем есть изрядное рациональное зерно. Правда, должен сказать, что за все время, что я работаю, у меня был всего один случай, когда я делал два очень похожих проекта. Да и то, надо сказать, что, при всей их схожести (виртуальные миры на одной и той же платформе с одной и той же командой) различий и нюансов оказалось достаточно для того, чтобы анализ сроков пришлось вести полностью заново.
Но, на самом деле, это всё не так уж и важно. Просто, похоже, мы с Вами являемся сторонниками разных методик и идеологий построения команды. Вам более нравится традиционная модель, с авторитетным — и авторитарным — начальством и с достаточно пассивными подчинёнными. Что ж, у нее есть изрядные достоинства. Например, намного проще и дешевле найти работников, от которых требуется исполнительность и узкая специализация.
Но мне ближе иная модель, в которой начальник является равноправным членом команды, и ответственность делится между всеми членами коллектива. На мой взгляд, такие команды, хоть и труднее в создании, но гораздо здоровее и более устойчивы. У традиционной команды начальник — это центральная точка отказа. Заболел он, впал в депрессию или просто ушёл — всё, работа встала. У команды моего типа отсутствие начальника вызывает чисто технические неудобства, и, в принципе, команда может спокойно продолжать работу в течении изрядного времени. Да и мне приятнее ощущать себя полноправным участником процесса, а не этаким Равшаном — Джумшутом от программирования. :)
Когда я даю такой ответ, то чётко предупреждаю: это — прикидка, предварительная оценка, estimate — или даже guesstimate. Да, бывают неадекватные менеджеры, которые не понимают, что такое «прикидка». Бывает также, что прикидка каким-то образом просачивается наверх, по пути загадочным образом превращаясь в точный срок. Но мне такие случаи практически не встречались. Гораздо чаще встречались программисты, которые не понимают, когда их просят сделать прикидку и сами не чувствуют разницы между прикидкой и планом. Они или абсолютно уверенно называют срок, или впадают в ступор и не могут ничего сказать даже приблизительно.
Ну вот хорошо, давайте возьмем этот вопрос для примера. Вы ведь уже начали давать на него вполне конструктивный ответ. Примитивный многопользовательский блог с более-менее стандартным дизайном потребует несколько дней. На полное воспроизведение функционала Хабра в нынешнем виде уйдёт… ну, давайте скажем, полгода работы двух программистов и дизайнера. Понятно, что время на построение коммьюнити (которая и есть Хабр!) мы не учитываем — тут я не специалист.
Мы получили вполне конструктивный ответ. Всем понятно, что ответ примерный, и на этом уровне точности полгода могут превратиться и в 8 месяцев — а могут оказаться и четырьмя. Но это заведомо не два года и не месяц. Насколько конструктивный был вопрос — судить трудно, но я вполне вижу кучу вариантов. Ну, например, на горизонте нарисовался инвестор, который хочет вложить деньги как раз во что-нибудь такого типа :)
Почему же «неконструктивные»? Вот пример из личного опыта. Для поддержки виртуальной экономики в игре, над которой я работал, использовались услуги некоей компании… ну, назовём её «Альфа». В какой-то момент ко мне подошёл менеджер и спросил: «Слушай, а сколько времени займёт написать свою версию этой Альфы?» (Как я понимаю, это и есть то самое «ТЗ из одной строки»). Я ответил на это, что, естественно, точно сказать трудно, но если речь идёт только о нужно нам функционале, то мы сможем воспроизвести его за 3-5 месяцев. Менеджер был вполне удовлетворён и ушёл дальше по свои менеджерским делам.
Был ли этот вопрос конструктивен? С его точки зрения — да, и весьма. Он пришёл с совещания, на котором обсуждался вопрос о том, как можно снизить затраты. «Альфа» за свои услуги брала с нас немаленькие деньги. Получив мой ответ, менеджер смог примерно прикинуть, окупится ли отказ от услуг «Альфы» и имеет ли смысл этим заниматься.
Менеджер, исходя из опыта, статистики и т. п. может примерно оценить время на разработку всего проекта. («Интернет-магазин? Да, моя команда уже сделала три магазина. Думаю, что мы уложимся в два с половиной месяца....») Однако точно он не сможет сказать, пока не поговорит с командой.
Дело же не в оценке эффективности работы, а в оценке сложности задачи. А кто с этим справится лучше, чем опытный исполнитель? (Да, младшим сотрудникам доверять самостоятельную оценку нельзя.)
При таком противодействии с человеком не хочется работать. Если я спрашиваю про сроки, я не ожидаю точного ответа, но завышение в пять раз я увижу. Если я говорю, что что-то нужно срочно, работник попросил «дописать до точки» и исчез на три часа, я поручу это дело другому работнику, более ответственному и адекватному, и задумаюсь о том, имеет ли смысл продолжать наше сотрудничество. А учитывая ещё и хамский неконструктивный тон остальных диалогов — мне кажется, ответ на этот вопрос становится очевидным.
Я сам программист, но вот не вижу в описываемых ситуациях ничего ужасного. Надо понять, что — в нормальной команде — и Вы, и менеджер делаете одно общее дело. Просто смотрите на него с немного разных сторон.
1. Да, конечно, вопрос, заданный невовремя, выбивает из рабочего ритма. (Правда, умение быстро входить в рабочее состояние — это часть квалификаци...) И не очень важно, о чём это вопрос. С другой стороны, бывает и так, что ответ действительно нужен срочно.
А что касается вопроса «Сколько займёт сделать?» — так начальник, как правило, и не ожидает точного ответа. На всякий случай это нао дроговорить — и спокойно дать прикидку, с пояснениями. Примерно так: «Вася, сколько времени займёт сделать онлайн-магазин?» — «Ну, Пётр Петрович, в лучшем случае, если простенький и стандартный, то можем взять готовый и за неделю его настроим и раскрасим. Ну, а если что-то шибко навороченное да нестандартное, то надо будет самим писать. Примерно за месяцев 6-9 сделаем». Вполне возможно, что начальника интересовало, не займет ли это год, и Вашг ответ его полностью устроит. И все будут довольны.
2. Такие ситуации происходят, когда программисты не держат менеджера в курсе происходящего. Конечно, когда программист сказал «За неделю сделаем», а работает уже почти месяц, к нему возникают вопросы. Возможно, задержка произошла из-за того, что менеджер подкидывал много изменений — но программист виноват в том, что не предупредил его о задержке: «Пётр Петрович, если вы хотите добавить в магазин функционал блэкджека, мы это сделаем — но это удлинит срок на… дайте прикинуть… примерно четыре дня.» Если программист это сделал, ответственность перешла к мэнеджеру, и ругать тот может только себя. Ну и о всяких проблемах надо сообщать: «Пётр Петрович, мы, когда обещали локализовать продукт для Израиля, не учли, что иврит пишется в другую сторону. Будет задержка — надо переделать дизайн.» Неприятно, конечно, но мэнеджер в курсе происходящего и сможет принять меры к тому, чтобы никакой катастрофы не случилось.
3. Могу только повторить: да, отвлекать нехорошо, и если это вошло у мэнеджера в привычку, его надо от этого отучать. Но бывает и так, что нужно срочно. Ведь бывает, правда?
4. Рефакторинг, заявленный как отдельная деятельность, никогда не вызывает восторга у менеджеров. Причины к тому разные, например, связанные с бухгалтерией. Решение тут очень простое: закладывать рефакторинг в оценку времени. И, опять-таки, все будут довольны.
5. Тут, возможно, имеет место непонимание. Возможно, мэнеджер предполагает, что в Ваши обязанности входит и вёрстка. (А возможно, так оно и есть!). В остальных случавях нужно просто объяснить мэнеджеру, что у Вас вёрстка получится долго, дорого и хреново, и что дешевле найти верстальщика.
В общем, главное — не раздражаться, а пытаться понять друг друга.
В школе надо закладывать основы. Мне кажется, что нужно вложить в головы школьников следующие мысли:
— Программирование опирается на серьёзный фундамент
(Двоичная система, основы дискретной математики, основы алгоритмов и структур данных)
— Программирование — это очень широкое и разнообразное поле деятельности
(2-3 ОЧЕНЬ разных языка — ну, например Питон, Хаскел, С, основы работы с базами данных, основы 3D, основы работы с сетями)
— Профессиональное программирование — это технологический процесс.
(Система контроля версий, багтрекер, обзор кода и т.п)
— Программирование — это интересно и здорово!
(Из всего вышеперечисленного сделать несколько интересных проектов, например, игры :) )
Проблема в том, что очень многие не понимают того, что такое «прототип», и думают, будто это — кое-как наспех сляпаная программа, которую когда-нибудь потом, в светлом будущем, перепишем.
На самом деле прототипирование — это особое занятие, тренбующее умения и понимания. Необходимо понимать, что каждый прототип должен преследовать некую четкую задачу, давать ответ на какой-то один вопрос. У проекта, таким образом, может быть много прототипов.
Кроме того, нужно различать прототипы, которые служат основанием для разработки, и выбрасываемые прототипы. Первые должны делаться по всем правилам, вторые могт быть написаны как угодно (хоть на другом языке и в другой среде, что, кстати, зачастую и делается), лишь бы они были дешёвые, делались очень быстро и помогали получить ответ на нужный вопрос.
И про поиски причины неудачи на стороне мне тоже не ясно. А если всё же причина кроется внутри команды, тогда что?
Но, на самом деле, это всё не так уж и важно. Просто, похоже, мы с Вами являемся сторонниками разных методик и идеологий построения команды. Вам более нравится традиционная модель, с авторитетным — и авторитарным — начальством и с достаточно пассивными подчинёнными. Что ж, у нее есть изрядные достоинства. Например, намного проще и дешевле найти работников, от которых требуется исполнительность и узкая специализация.
Но мне ближе иная модель, в которой начальник является равноправным членом команды, и ответственность делится между всеми членами коллектива. На мой взгляд, такие команды, хоть и труднее в создании, но гораздо здоровее и более устойчивы. У традиционной команды начальник — это центральная точка отказа. Заболел он, впал в депрессию или просто ушёл — всё, работа встала. У команды моего типа отсутствие начальника вызывает чисто технические неудобства, и, в принципе, команда может спокойно продолжать работу в течении изрядного времени. Да и мне приятнее ощущать себя полноправным участником процесса, а не этаким Равшаном — Джумшутом от программирования. :)
Мы получили вполне конструктивный ответ. Всем понятно, что ответ примерный, и на этом уровне точности полгода могут превратиться и в 8 месяцев — а могут оказаться и четырьмя. Но это заведомо не два года и не месяц. Насколько конструктивный был вопрос — судить трудно, но я вполне вижу кучу вариантов. Ну, например, на горизонте нарисовался инвестор, который хочет вложить деньги как раз во что-нибудь такого типа :)
Был ли этот вопрос конструктивен? С его точки зрения — да, и весьма. Он пришёл с совещания, на котором обсуждался вопрос о том, как можно снизить затраты. «Альфа» за свои услуги брала с нас немаленькие деньги. Получив мой ответ, менеджер смог примерно прикинуть, окупится ли отказ от услуг «Альфы» и имеет ли смысл этим заниматься.
Дело же не в оценке эффективности работы, а в оценке сложности задачи. А кто с этим справится лучше, чем опытный исполнитель? (Да, младшим сотрудникам доверять самостоятельную оценку нельзя.)
1. Да, конечно, вопрос, заданный невовремя, выбивает из рабочего ритма. (Правда, умение быстро входить в рабочее состояние — это часть квалификаци...) И не очень важно, о чём это вопрос. С другой стороны, бывает и так, что ответ действительно нужен срочно.
А что касается вопроса «Сколько займёт сделать?» — так начальник, как правило, и не ожидает точного ответа. На всякий случай это нао дроговорить — и спокойно дать прикидку, с пояснениями. Примерно так: «Вася, сколько времени займёт сделать онлайн-магазин?» — «Ну, Пётр Петрович, в лучшем случае, если простенький и стандартный, то можем взять готовый и за неделю его настроим и раскрасим. Ну, а если что-то шибко навороченное да нестандартное, то надо будет самим писать. Примерно за месяцев 6-9 сделаем». Вполне возможно, что начальника интересовало, не займет ли это год, и Вашг ответ его полностью устроит. И все будут довольны.
2. Такие ситуации происходят, когда программисты не держат менеджера в курсе происходящего. Конечно, когда программист сказал «За неделю сделаем», а работает уже почти месяц, к нему возникают вопросы. Возможно, задержка произошла из-за того, что менеджер подкидывал много изменений — но программист виноват в том, что не предупредил его о задержке: «Пётр Петрович, если вы хотите добавить в магазин функционал блэкджека, мы это сделаем — но это удлинит срок на… дайте прикинуть… примерно четыре дня.» Если программист это сделал, ответственность перешла к мэнеджеру, и ругать тот может только себя. Ну и о всяких проблемах надо сообщать: «Пётр Петрович, мы, когда обещали локализовать продукт для Израиля, не учли, что иврит пишется в другую сторону. Будет задержка — надо переделать дизайн.» Неприятно, конечно, но мэнеджер в курсе происходящего и сможет принять меры к тому, чтобы никакой катастрофы не случилось.
3. Могу только повторить: да, отвлекать нехорошо, и если это вошло у мэнеджера в привычку, его надо от этого отучать. Но бывает и так, что нужно срочно. Ведь бывает, правда?
4. Рефакторинг, заявленный как отдельная деятельность, никогда не вызывает восторга у менеджеров. Причины к тому разные, например, связанные с бухгалтерией. Решение тут очень простое: закладывать рефакторинг в оценку времени. И, опять-таки, все будут довольны.
5. Тут, возможно, имеет место непонимание. Возможно, мэнеджер предполагает, что в Ваши обязанности входит и вёрстка. (А возможно, так оно и есть!). В остальных случавях нужно просто объяснить мэнеджеру, что у Вас вёрстка получится долго, дорого и хреново, и что дешевле найти верстальщика.
В общем, главное — не раздражаться, а пытаться понять друг друга.
Это, похоже, ссылка на книгу Откровения, глава 22 стих 12:
«Се, гряду скоро, и возмездие Мое со Мною, чтобы воздать каждому по делам его. „
В английском варианте:
“And, behold, I come quickly; and my reward is with me, to give every man according as his work shall be.»
— Программирование опирается на серьёзный фундамент
(Двоичная система, основы дискретной математики, основы алгоритмов и структур данных)
— Программирование — это очень широкое и разнообразное поле деятельности
(2-3 ОЧЕНЬ разных языка — ну, например Питон, Хаскел, С, основы работы с базами данных, основы 3D, основы работы с сетями)
— Профессиональное программирование — это технологический процесс.
(Система контроля версий, багтрекер, обзор кода и т.п)
— Программирование — это интересно и здорово!
(Из всего вышеперечисленного сделать несколько интересных проектов, например, игры :) )
На самом деле прототипирование — это особое занятие, тренбующее умения и понимания. Необходимо понимать, что каждый прототип должен преследовать некую четкую задачу, давать ответ на какой-то один вопрос. У проекта, таким образом, может быть много прототипов.
Кроме того, нужно различать прототипы, которые служат основанием для разработки, и выбрасываемые прототипы. Первые должны делаться по всем правилам, вторые могт быть написаны как угодно (хоть на другом языке и в другой среде, что, кстати, зачастую и делается), лишь бы они были дешёвые, делались очень быстро и помогали получить ответ на нужный вопрос.