суббота, 2 октября 2010 г.

Как вы можете убедить разработчиков платить их "налоги"?

Это перевод How do you convince developers to pay their "taxes"? Автор: Реймонд Чен.

В этом году перед командой Tablet PC стоит тяжёлая задача на конференции PDC: они должны убедить людей обращать внимание на управление питанием (power management).

Причина, почему это тяжело, заключается в том, что управление питанием с трудом можно назвать важной задачей. Если пользователь пробует, скажем, программу персонального бух-учёта, сколько усилий он потратит на оценку того, как много программы жрёт ресурса батареи? Это, вероятно, третий или четвёртый тайбрейк. Как бы умело ваша программа не обращалась с питанием - это не перевесит тот факт, что её интерфейс сложнее использовать, чем интерфейс программы-конкурента. Никто в жизни не скажет такого: "Да, я перешёл на текстовый процессор Y с X, потому что X тратил слишком много энергии". Когда батарея быстро заканчивается, пользователи обычно ругают батарею, а не программы, которые её используют.

Управление питанием попадает в категорию, которую некоторые команды разработчиков называют "налогами". Это что-то такое, что вы делаете не потому, что это принесёт выгоду конкретно вам, а потому что это принесёт выгоду чему-то большему: общей экосистеме приложений. Ещё примеры "налогов": убедиться, что ваша программа дружелюбна к перемещаемым профилям пользователя, быстрому переключению пользователей, иерархическому управлению носителями, геополитике, многомониторным конфигурациям, удалённому рабочему столу и 64-х битным Windows.

Конечно же, не все команды разработчиков в мире настолько прилежны, чтобы оплатить все свои "налоги". Я подозреваю, что большинство обманывают свою "налоговую", а некоторые из них просто не платят вообще.

Так что, вот мой вопрос к вам: как вы убедите разработчиков выплачивать свои "налоги"? (и должны ли разработчики платить налоги вообще?)

15 комментариев:

  1. Лучше всего, если этот налог возьмет на себя фреймвор, что бы избавить разработчика от необходимости прорабатывать рутинные задачи, в прямую не добавляющие ценности в продукт.

    ОтветитьУдалить
  2. Как как :)
    Так же как и в любой другой отрасли. Если заказчик платит "за налоги", то он будут реализованы. Если не платит, то, соотвественно нет.
    Вопрос заряда батарейки в программе должен волновать заказчика программы. А исполнителя должна волновать лишь сумма оплаты за беспокойство относительно батарейки.

    ОтветитьУдалить
  3. Как насчёт коробочных продуктов?

    Кто является заказчиком WinRAR, Total Commander, Windows, Office?

    ОтветитьУдалить
  4. У коробочного продукта точно так же есть заказчик.
    Заказчик это тот, кто заказывает разработку платит деньги.
    У любого продукта есть заказчик. Даже у такого, который человек пишет сам для себя. Вот сколько заказчик отвел средств и времени на налоги, настолько они и будут реализованы.
    Это касается не только "налогов". Но и любого функционала вообще. Что оплачено-то реалиовано.

    ОтветитьУдалить
  5. Я имею ввиду именно заказчика а не потребителя.

    ОтветитьУдалить
  6. Не, ну тогда это какое-то перекладывание с одной головы на другую.

    Какая разница, как вы назовёте человека, который принимает решения: разработчик, менеджер, заказчик. Суть-то от этого не изменится: этот человек (кем бы он ни был) не заинтересован в трате ресурсов на вещи, которые не приносят ему выгоды. В этом-то вопрос и состоит: что с этим можно делать?

    Насчёт фреймворка - это, конечно, правильно. Та же VCL, к примеру, скрывает под капотом множество вещей, о которых программисты не задумываются (равно как и не покрывает некоторые налоги). Но только вот это лишь малая часть налогов.

    К примеру, геополитика, HSM, 64bit, roaming profiles - это всё то, что не может быть учтено фреймворком, потому что относится к общему дизайну программы, её логике верхнего уровня, которую пишет программист, а не нижележащих уровней (которые покрывают фреймворки и API).

    ОтветитьУдалить
  7. Он не принимает решения. Он платит деньги. За что он платит, то значит и важно. Заказчику всегда виднее. И тот же пример с батарейкой весьма примечателен. Вы же сами ответили на свой вопрос. Если батарейка садится, то винят батарейку. А если батарейка не садится, то этого не замечают.
    Кто платит, то и решает. А наше програмистское дело кнопки нажимать за деньги. Что скажут, то и делать. А если не нравится, то становись сам себе заказчиком и сам себя финансируй и делай что хочешь.
    Как-то так.

    ОтветитьУдалить
  8. Мне кажется, мы друг друга не понимаем.

    По моему мнению тут вопрос не в том, кто выделяет ресурсы (не важно - деньги или время). А вопрос в том, как их заставить их вообще выделять на вещи, которые не приносят прямой выгоды.

    Ну вот стал ты сам себе хозяином, выпускаешь коробочный продукт. Вопрос: что заставит тебя тратить своё время на шлифовку таких вещей, если вместо этого ты можешь потратить это время гораздо более выгоднее: на реализацию новых фишек программы, которые затем можно продать.

    Это я к тому, что заметка вроде не про это: "Если заказчик платит "за налоги", то он будут реализованы. Если не платит, то, соотвественно нет."

    Это как раз понятно. Выделяет кто-то ресурсы - дела делаются. Не выделяет - не делаются. А как заставить их выделять ресурсы в принципе?

    К примеру, практика показывает, что популярные программы часто имеют далёкий от идеального код. Гразный код, код с хаками, код непродуманный. Но никого это не волнует - ведь он делает своё дело.

    Речь о том, что мы хотим улучшить экосистему приложений, мы хотим, чтобы код в целом стал чище, правильнее, идеальнее. Как мы видим, следование принципу "заказчик хочет - платит деньги" этого результата не приносит. Скорее даже наоборот.

    ОтветитьУдалить
  9. К примеру, из позитивных подходов: обучение - расширять кругозор и знания разработчиков. Потому что код часто бывает ужасен не потому, что на это внимания не обращают, а потому, что разработчикам просто никто не сказал, как делать правильно. Как только они это узнают - они будут делать правильно на автомате.

    Ещё пример: многие программисты чувствуют необходимость делать вещи правильно. Они испытывают удовлетворение от правильного кода и стремятся исправить плохой код. И снова: нужно дать им знать, как нужно поступать правильно.

    Ещё способ, хоть и крайне ограниченный: автоматизация проверок. Какой-нибудь плагин к IDE, который проверяет типичные "misuses" и выдаёт варнинги. Конечно, далеко не всё можно так проверить, но всё же.

    Можно и так попробовать: говорить, что если они пишут плохой код, то их конкуренты этим воспользуются: они будут писать хороший код. Конечно, само по себе это не отбивает пользователей. Но при прочих равных - вполне может. Когда пользователи замечают, что один продукт отшлифован лучше другого.

    Вот ещё способ, весьма, пожалуй, действенный: сертификация программ. Очевидно, что наличие наклейки на коробке "Эта программа прошла сертификацию X" крайне положительно сказывается на конкурентоспособности вашей программы. Вот как раз эта сертификация и может выполнять кой-какие проверки на "выплаты налогов".

    А вот сценарий с "заказчиком" не работает. Предположим, вы хотите улучшить X в программе/коде. Ну, вот потому что так надо, так правильно. Вы говорите заказчику: нам надо улучшить X. А он: хорошо, а что за бизнес-сценарий соответствует X? Что вы ему ответите? Что это надо, потому что надо? Пожалуй, он может рассмеяться вам в лицо. Примером кода, который получается с таким подходом, являются всевозможные программы гос-предприятий (ПФР и т.п.). Большая часть из них являются простыми клиентами к какой-либо БД. Но почему-то часто папка установки фиксирована, программа не работает под ограниченными учётками и т.п. ужасы. Вот всё как раз потому, что делается ровно то, что хочет заказчик ("работает - и ладно"), и не граммом больше (потому что зачастую квалификация программистов не позволяет писать лучший код).

    Как-то так, мне кажется.

    ОтветитьУдалить
  10. >Вот всё как раз потому, что делается ровно то, что хочет заказчик.
    Вот с этим я полностью согласен. Именно так и должно быть. Этим и отличается профессионал от любителя. профессионал делает то, что нужно заказчику за минимальное время и ресурсы, а любитель будет отвлекаться на всякую ерунду. Если заказчика устраивает то, что программа работает только под админом, а не под ограниченной учеткой, значит программист справился с задачей. А если не устравивает, то заказчик платит за то, чтобы она работала везде.
    А если программист делает такие вещи по личной инициативе, то это на самом деле называется воровством денег из кармана заказчика и неэффектианой работой.
    Если человека просят забить гвоздь, то нужно забить гвоздь, а не полировать его и не покрывать лаком.
    Другое дело, что техническое задание очень часто отличается от того, что хотел заказчик. Но это вопрос опять-таки не к программистам-исполнителям, а к разработчикам технического задания. заказчик может и не знать о всех тонкостях работы с учетными записями. Ему это и не нужно. для этого есть команда разработчиков ТЗ. Как раз таки именно в их служебные обязанности входит определение этих самых нюансов и "налогов". Обоснование их необходимости заказчику и добыча финансирования.
    Вот на что добыли, то и нужно делать.
    Ну это мне как-то так кажется :)
    А в целом очень приятно с Вами подискутировать!

    ОтветитьУдалить
  11. >>> Если заказчика устраивает то, что программа работает только под админом, а не под ограниченной учеткой, значит программист справился с задачей.

    Понимаете, заказчик же в этом ничего не понимает. Он не говорит сделать ровно вот так. Он хочет, чтобы ему сделали функциональность A. А как её реализовать - он понятия не имеет (да и не должен). Грубо говоря, заказчик не говорит: "забей гвоздь", он говорит: "сделай мне офигенную кухню, как у Билл Гейтса". Он понятия не имеет, как это надо делать. Да он и слов-то таких не знает. Это - наша работа.

    Так вот её (функциональность A) можно сделать правильно (с точки зрения общей экосистемы ПО) и неправильно. Работать A будет в обоих случаях. Затраты на это... ну, зависит, конечно - можно на "правильную" реализацию затратить больше усилий, а можно и наоборот.

    Если делать абы как, то потом заказчик может оказаться в ситуации, когда он заказывал Мерседес, а получил нечто... гм, работающее. Только почему-то розового цвета и склеенное скотчем. И потом оказывается: "Ребята, а чего это оно...?" - "Дак вы ж не просили!". Оно, как-бы, понятно, "на что дововариваемся - то и получаем", но я про то, что программные долги - это технические моменты, а не функциональные. Их во многом определяет разработчик.

    Кстати, вопрос ведь не только в единовременном вкладе ресурсов: программа, более дружественная к окружению, вероятно, будет дешевле в поддержке.

    В любом случае, повторюсь, вопрос тут немного не в том. Исходная заметка написана программистом Windows (не в смысле "под Windows", а в смысле одним из авторов). Так что он говорит с позиции разработчика ОС. Т.е. вопрос поставлен "как заставить "заказчика" (того, кто принимает решения) обращать на это внимание".

    Ну, знаете, грубо говоря, это примерно как мэр города пишет: "хм, как бы заставить людей не мусорить на улицах города? Поставить урны? Нанять дворников? Учить в школе?". Понятно, что мусорить или нет - это личная инициатива каждого. Но вопрос поставлен со стороны пастуха.

    ОтветитьУдалить
  12. >>> Ему это и не нужно. для этого есть команда разработчиков ТЗ

    Ай, что-то я увлёкся и это пропустил. Извиняюсь.

    ОтветитьУдалить
  13. (заметка себе на будущее: сначала надо проснуться, а потом отвечать на комментарии)

    ОтветитьУдалить
  14. Если заказчика устраивает то, что программа работает только под админом, а не под ограниченной учеткой, значит программист справился с задачей. А если не устравивает, то заказчик платит за то, чтобы она работала везде.
    Вот от таких людей и появляются программные уродцы с фиксированной папкой установки (причем в корне диска C:\), обязательно требующие админских прав (причем из-за какой-нибудь элементарной лабуды), разъезжающиеся вкривь и вкось при любом изменении системного размера шрифта (про dpi уж молчу).
    Продолжая аналогию с машинами: покупая новое авто, ты едва ли даже подумаешь спросить, поддерживает ли оно функцию парковки в произвольном гараже (а не одном фиксированном, указанном производителем и находящимся в Зимбабве). Или что окна на нем можно открывать в любую погоду (а на деле получается, что из-за непродуманной системы обогрева при t < 0 всё стекло замерзает нахрен). Или что операция заправки бака требует хитрожопого электронного устройства, которое есть только в официальных сервисах, которых всего 2 на всю страну.

    ОтветитьУдалить
  15. Наш автопром, например, именно по такому принципу работает - потому и находится в глубоком анусе. "А че, колеса четыре, даже ездит иногда - ну и отлично, завод справился с задачей. А за то, чтоб было удобно пользоваться, нам не платили". Делать надо для людей, а не только то, за что заплатили и что прописано в ТЗ.
    В противном случае вашу карму программера отяготят многие тысячи проклятий от юзеров, и не видать вам должности project manager в следующей инкарнации :)

    ОтветитьУдалить

Можно использовать некоторые HTML-теги, например:

<b>Жирный</b>
<i>Курсив</i>
<a href="http://www.example.com/">Ссылка</a>

Вам необязательно регистрироваться для комментирования - для этого просто выберите из списка "Анонимный" (для анонимного комментария) или "Имя/URL" (для указания вашего имени и ссылки на сайт). Все прочие варианты потребуют от вас входа в вашу учётку (поддерживается OpenID).

Пожалуйста, по возможности используйте "Имя/URL" вместо "Анонимный". URL можно просто не указывать.

Ваше сообщение может быть помечено как спам спам-фильтром - не волнуйтесь, оно появится после проверки администратором.