Что такое "сложно"

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

Знакомая ситуация: начальник обращается к программисту с предложением (требованием, угрозой — нужное подчеркнуть :-) ) реализовать какую-нибудь нужную вещь в системе, на что тот, не долго думая, отвечает: "не, это сложно..." Тут же возникает конфликт, потому что начальнику эта самая вещь кажется далеко не такой сложной, и он подозревает, что программист просто ленится.

Ситуация эта, вопреки бытующему мнению, не является никаким "необходимым злом" в общении с программистами и вполне разрешаема.

Но начать я хочу с выяснения того, что такое на самом деле "сложно". Я готов предложить очень простое формальное определение этого понятия.

Определение

Сложно — это то, что ваш программист называет сложным.

Легче не стало :-). Но это ведь формальное определение, а оно всегда нуждается в дальнейших разъяснениях.

Что это определение подразумевает в первую очередь — это то, что сложность невозможно померять объективно в каких-то взвешенных единицах. Это всегда субъективное понятие. Для программиста графических интерфейсов задача подвешивания к веб-сайту RSS-потока включает знакомство с другим языком программирования, чтение статей "что такое RSS", потом "что такое XML", потом "как делать XML в PHP". Это сложно. Веб-программиста это займет на какой-нибудь час, потому что та бибилиотека, с которой он работает, содержит волшебную функцию "повесить RSS-поток на сайт", и он про нее знает (час уйдет на уточнение того, что же именно будет в потоке, и где же именно разместить иконочку). Кроме специализации огромное значение имеет авторство кода. Починить свой баг на порядок проще, чем чужой, даже если они из одного и того же раздела программирования.

Само слово "программист" в определении тоже имеет смысл. Большое заблуждение многих заключается в том, что программирование — это такая же работа, как, скажем, бухгалтерия, и любой человек может быть программистом, если прочитает несколько умных книжек и потренируется. На самом деле это не так. Способность программировать — это своего рода талант, который можно сравнить со способностью рисовать картины.

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

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

Дальше все проще. "Сложно — это то, что ваш программист называет сложным." Это означает, что раз работу выполнять именно ему(ей), то его(ее) мнение и является определяющим. Да, возможно вам задача кажется простой. Да, возможно вы убеждены, что ему(ей) просто лень подумать. Да, возможно вы считаете, что ваш программист уже полтора года применяет не те языки, библиотеки и фреймворки, и вообще в .NET (J2EE, ASP, SAP — любимое подчеркнуть) все это работает само. Это, очевидно, не имеет ровно никакого значения, потому что ваш программист умеет то, что он(она) умеет, а вы не возьметесь программировать вместо него(нее).

И маленькое дополнение: если вы скажете ему(ей) о том, что его(ее) инструменты — отстой, это не будет являться дополнительной мотивацией.

Чаще всего, на самом деле, имеет место и то, и другое: и задача сложней, чем кажется, и у программиста мозги заняты совсем другим. Вот это и есть — практическая сложность. И ее надо решать.

Решение задачи

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

Вместо этого надо добавить к вопросу еще одну метрику помимо сложности — важность. По личному опыту скажу, что часто программисты, отвечая на вопрос "а не сложно ли будет...", отвечают на уже следующий вопрос: стоит ли важность задачи времени на ее реализацию. Многие программисты считают (и часто вполне обосновано), что достаточно хорошо представляют себе общую ситуацию, чтобы сразу сделать вывод об общей целесобразности работы. И этим ответом просто стараются сэкономить всем время.

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

И последнее замечание. Задача программиста — программировать. А организовывать процесс программирования, в который входит и взаимооценка сложности с важностью — это ваша задача, дорогие руководители.