Это перевод How do you convince developers to pay their "taxes"? Автор: Реймонд Чен. Входит в книгу The Old New Thing.
В этом году перед командой Tablet PC стоит тяжёлая задача на конференции PDC: они должны убедить людей обращать внимание на управление питанием (power management).
Причина, почему это тяжело, заключается в том, что управление питанием с трудом можно назвать важной задачей. Если пользователь пробует, скажем, программу персонального бух-учёта, сколько усилий он потратит на оценку того, как много программы жрёт ресурса батареи? Это, вероятно, третий или четвёртый тайбрейк. Как бы умело ваша программа не обращалась с питанием - это не перевесит тот факт, что её интерфейс сложнее использовать, чем интерфейс программы-конкурента. Никто в жизни не скажет такого: "Да, я перешёл на текстовый процессор Y с X, потому что X тратил слишком много энергии". Когда батарея быстро заканчивается, пользователи обычно ругают батарею, а не программы, которые её используют.
Управление питанием попадает в категорию, которую некоторые команды разработчиков называют "налогами". Это что-то такое, что вы делаете не потому, что это принесёт выгоду конкретно вам, а потому что это принесёт выгоду чему-то большему: общей экосистеме приложений. Ещё примеры "налогов": убедиться, что ваша программа дружелюбна к перемещаемым профилям пользователя, быстрому переключению пользователей, иерархическому управлению носителями, геополитике, многомониторным конфигурациям, удалённому рабочему столу и 64-х битным Windows.
Конечно же, не все команды разработчиков в мире настолько прилежны, чтобы оплатить все свои "налоги". Я подозреваю, что большинство обманывают свою "налоговую", а некоторые из них просто не платят вообще.
Так что, вот мой вопрос к вам: как вы убедите разработчиков выплачивать свои "налоги"? (и должны ли разработчики платить налоги вообще?)
...when altering one's mind becomes as easy as programming a computer, what does it mean to be human?..
суббота, 2 октября 2010 г.
15 комментариев:
Можно использовать некоторые HTML-теги, например:
<b>Жирный</b>
<i>Курсив</i>
<a href="http://www.example.com/">Ссылка</a>
Вам необязательно регистрироваться для комментирования - для этого просто выберите из списка "Анонимный" (для анонимного комментария) или "Имя/URL" (для указания вашего имени и ссылки на сайт). Все прочие варианты потребуют от вас входа в вашу учётку.
Пожалуйста, по возможности используйте "Имя/URL" вместо "Анонимный". URL можно просто не указывать.
Ваше сообщение может быть помечено как спам спам-фильтром - не волнуйтесь, оно появится после проверки администратором.
Примечание. Отправлять комментарии могут только участники этого блога.
Подписаться на:
Комментарии к сообщению (Atom)
Лучше всего, если этот налог возьмет на себя фреймвор, что бы избавить разработчика от необходимости прорабатывать рутинные задачи, в прямую не добавляющие ценности в продукт.
ОтветитьУдалитьКак как :)
ОтветитьУдалитьТак же как и в любой другой отрасли. Если заказчик платит "за налоги", то он будут реализованы. Если не платит, то, соотвественно нет.
Вопрос заряда батарейки в программе должен волновать заказчика программы. А исполнителя должна волновать лишь сумма оплаты за беспокойство относительно батарейки.
Как насчёт коробочных продуктов?
ОтветитьУдалитьКто является заказчиком WinRAR, Total Commander, Windows, Office?
У коробочного продукта точно так же есть заказчик.
ОтветитьУдалитьЗаказчик это тот, кто заказывает разработку платит деньги.
У любого продукта есть заказчик. Даже у такого, который человек пишет сам для себя. Вот сколько заказчик отвел средств и времени на налоги, настолько они и будут реализованы.
Это касается не только "налогов". Но и любого функционала вообще. Что оплачено-то реалиовано.
Я имею ввиду именно заказчика а не потребителя.
ОтветитьУдалитьНе, ну тогда это какое-то перекладывание с одной головы на другую.
ОтветитьУдалитьКакая разница, как вы назовёте человека, который принимает решения: разработчик, менеджер, заказчик. Суть-то от этого не изменится: этот человек (кем бы он ни был) не заинтересован в трате ресурсов на вещи, которые не приносят ему выгоды. В этом-то вопрос и состоит: что с этим можно делать?
Насчёт фреймворка - это, конечно, правильно. Та же VCL, к примеру, скрывает под капотом множество вещей, о которых программисты не задумываются (равно как и не покрывает некоторые налоги). Но только вот это лишь малая часть налогов.
К примеру, геополитика, HSM, 64bit, roaming profiles - это всё то, что не может быть учтено фреймворком, потому что относится к общему дизайну программы, её логике верхнего уровня, которую пишет программист, а не нижележащих уровней (которые покрывают фреймворки и API).
Он не принимает решения. Он платит деньги. За что он платит, то значит и важно. Заказчику всегда виднее. И тот же пример с батарейкой весьма примечателен. Вы же сами ответили на свой вопрос. Если батарейка садится, то винят батарейку. А если батарейка не садится, то этого не замечают.
ОтветитьУдалитьКто платит, то и решает. А наше програмистское дело кнопки нажимать за деньги. Что скажут, то и делать. А если не нравится, то становись сам себе заказчиком и сам себя финансируй и делай что хочешь.
Как-то так.
Мне кажется, мы друг друга не понимаем.
ОтветитьУдалитьПо моему мнению тут вопрос не в том, кто выделяет ресурсы (не важно - деньги или время). А вопрос в том, как их заставить их вообще выделять на вещи, которые не приносят прямой выгоды.
Ну вот стал ты сам себе хозяином, выпускаешь коробочный продукт. Вопрос: что заставит тебя тратить своё время на шлифовку таких вещей, если вместо этого ты можешь потратить это время гораздо более выгоднее: на реализацию новых фишек программы, которые затем можно продать.
Это я к тому, что заметка вроде не про это: "Если заказчик платит "за налоги", то он будут реализованы. Если не платит, то, соотвественно нет."
Это как раз понятно. Выделяет кто-то ресурсы - дела делаются. Не выделяет - не делаются. А как заставить их выделять ресурсы в принципе?
К примеру, практика показывает, что популярные программы часто имеют далёкий от идеального код. Гразный код, код с хаками, код непродуманный. Но никого это не волнует - ведь он делает своё дело.
Речь о том, что мы хотим улучшить экосистему приложений, мы хотим, чтобы код в целом стал чище, правильнее, идеальнее. Как мы видим, следование принципу "заказчик хочет - платит деньги" этого результата не приносит. Скорее даже наоборот.
К примеру, из позитивных подходов: обучение - расширять кругозор и знания разработчиков. Потому что код часто бывает ужасен не потому, что на это внимания не обращают, а потому, что разработчикам просто никто не сказал, как делать правильно. Как только они это узнают - они будут делать правильно на автомате.
ОтветитьУдалитьЕщё пример: многие программисты чувствуют необходимость делать вещи правильно. Они испытывают удовлетворение от правильного кода и стремятся исправить плохой код. И снова: нужно дать им знать, как нужно поступать правильно.
Ещё способ, хоть и крайне ограниченный: автоматизация проверок. Какой-нибудь плагин к IDE, который проверяет типичные "misuses" и выдаёт варнинги. Конечно, далеко не всё можно так проверить, но всё же.
Можно и так попробовать: говорить, что если они пишут плохой код, то их конкуренты этим воспользуются: они будут писать хороший код. Конечно, само по себе это не отбивает пользователей. Но при прочих равных - вполне может. Когда пользователи замечают, что один продукт отшлифован лучше другого.
Вот ещё способ, весьма, пожалуй, действенный: сертификация программ. Очевидно, что наличие наклейки на коробке "Эта программа прошла сертификацию X" крайне положительно сказывается на конкурентоспособности вашей программы. Вот как раз эта сертификация и может выполнять кой-какие проверки на "выплаты налогов".
А вот сценарий с "заказчиком" не работает. Предположим, вы хотите улучшить X в программе/коде. Ну, вот потому что так надо, так правильно. Вы говорите заказчику: нам надо улучшить X. А он: хорошо, а что за бизнес-сценарий соответствует X? Что вы ему ответите? Что это надо, потому что надо? Пожалуй, он может рассмеяться вам в лицо. Примером кода, который получается с таким подходом, являются всевозможные программы гос-предприятий (ПФР и т.п.). Большая часть из них являются простыми клиентами к какой-либо БД. Но почему-то часто папка установки фиксирована, программа не работает под ограниченными учётками и т.п. ужасы. Вот всё как раз потому, что делается ровно то, что хочет заказчик ("работает - и ладно"), и не граммом больше (потому что зачастую квалификация программистов не позволяет писать лучший код).
Как-то так, мне кажется.
>Вот всё как раз потому, что делается ровно то, что хочет заказчик.
ОтветитьУдалитьВот с этим я полностью согласен. Именно так и должно быть. Этим и отличается профессионал от любителя. профессионал делает то, что нужно заказчику за минимальное время и ресурсы, а любитель будет отвлекаться на всякую ерунду. Если заказчика устраивает то, что программа работает только под админом, а не под ограниченной учеткой, значит программист справился с задачей. А если не устравивает, то заказчик платит за то, чтобы она работала везде.
А если программист делает такие вещи по личной инициативе, то это на самом деле называется воровством денег из кармана заказчика и неэффектианой работой.
Если человека просят забить гвоздь, то нужно забить гвоздь, а не полировать его и не покрывать лаком.
Другое дело, что техническое задание очень часто отличается от того, что хотел заказчик. Но это вопрос опять-таки не к программистам-исполнителям, а к разработчикам технического задания. заказчик может и не знать о всех тонкостях работы с учетными записями. Ему это и не нужно. для этого есть команда разработчиков ТЗ. Как раз таки именно в их служебные обязанности входит определение этих самых нюансов и "налогов". Обоснование их необходимости заказчику и добыча финансирования.
Вот на что добыли, то и нужно делать.
Ну это мне как-то так кажется :)
А в целом очень приятно с Вами подискутировать!
>>> Если заказчика устраивает то, что программа работает только под админом, а не под ограниченной учеткой, значит программист справился с задачей.
ОтветитьУдалитьПонимаете, заказчик же в этом ничего не понимает. Он не говорит сделать ровно вот так. Он хочет, чтобы ему сделали функциональность A. А как её реализовать - он понятия не имеет (да и не должен). Грубо говоря, заказчик не говорит: "забей гвоздь", он говорит: "сделай мне офигенную кухню, как у Билл Гейтса". Он понятия не имеет, как это надо делать. Да он и слов-то таких не знает. Это - наша работа.
Так вот её (функциональность A) можно сделать правильно (с точки зрения общей экосистемы ПО) и неправильно. Работать A будет в обоих случаях. Затраты на это... ну, зависит, конечно - можно на "правильную" реализацию затратить больше усилий, а можно и наоборот.
Если делать абы как, то потом заказчик может оказаться в ситуации, когда он заказывал Мерседес, а получил нечто... гм, работающее. Только почему-то розового цвета и склеенное скотчем. И потом оказывается: "Ребята, а чего это оно...?" - "Дак вы ж не просили!". Оно, как-бы, понятно, "на что дововариваемся - то и получаем", но я про то, что программные долги - это технические моменты, а не функциональные. Их во многом определяет разработчик.
Кстати, вопрос ведь не только в единовременном вкладе ресурсов: программа, более дружественная к окружению, вероятно, будет дешевле в поддержке.
В любом случае, повторюсь, вопрос тут немного не в том. Исходная заметка написана программистом Windows (не в смысле "под Windows", а в смысле одним из авторов). Так что он говорит с позиции разработчика ОС. Т.е. вопрос поставлен "как заставить "заказчика" (того, кто принимает решения) обращать на это внимание".
Ну, знаете, грубо говоря, это примерно как мэр города пишет: "хм, как бы заставить людей не мусорить на улицах города? Поставить урны? Нанять дворников? Учить в школе?". Понятно, что мусорить или нет - это личная инициатива каждого. Но вопрос поставлен со стороны пастуха.
>>> Ему это и не нужно. для этого есть команда разработчиков ТЗ
ОтветитьУдалитьАй, что-то я увлёкся и это пропустил. Извиняюсь.
(заметка себе на будущее: сначала надо проснуться, а потом отвечать на комментарии)
ОтветитьУдалитьЕсли заказчика устраивает то, что программа работает только под админом, а не под ограниченной учеткой, значит программист справился с задачей. А если не устравивает, то заказчик платит за то, чтобы она работала везде.
ОтветитьУдалитьВот от таких людей и появляются программные уродцы с фиксированной папкой установки (причем в корне диска C:\), обязательно требующие админских прав (причем из-за какой-нибудь элементарной лабуды), разъезжающиеся вкривь и вкось при любом изменении системного размера шрифта (про dpi уж молчу).
Продолжая аналогию с машинами: покупая новое авто, ты едва ли даже подумаешь спросить, поддерживает ли оно функцию парковки в произвольном гараже (а не одном фиксированном, указанном производителем и находящимся в Зимбабве). Или что окна на нем можно открывать в любую погоду (а на деле получается, что из-за непродуманной системы обогрева при t < 0 всё стекло замерзает нахрен). Или что операция заправки бака требует хитрожопого электронного устройства, которое есть только в официальных сервисах, которых всего 2 на всю страну.
Наш автопром, например, именно по такому принципу работает - потому и находится в глубоком анусе. "А че, колеса четыре, даже ездит иногда - ну и отлично, завод справился с задачей. А за то, чтоб было удобно пользоваться, нам не платили". Делать надо для людей, а не только то, за что заплатили и что прописано в ТЗ.
ОтветитьУдалитьВ противном случае вашу карму программера отяготят многие тысячи проклятий от юзеров, и не видать вам должности project manager в следующей инкарнации :)