fisher (raa) wrote,
fisher
raa

простые вещи

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


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

И вот тут оказывается, что именно технический менеджмент начинает играть чуть ли не ключевую роль. Это очень непривычно остальным не-технарям, которые никогда не понимали этот странный технический народец, которым, казалось бы, волю дай и весь смысл их существования сведётся к одному - к развлечению за наш счёт. Знакомо? Ну то-то. Начинается интересная история, к которой я так медленно подвожу своего уважаемого читателя, но прежде мне стоит сделать ещё одно отступление. Для меня оно особенно важно, поскольку большинство моих читателей, да и сам я наполовину - программисты. Так вот, господа, нужно четко понимать, что решения о том, куда идет компания, какие у неё цели, и как она их будет достигать - на стратегическом уровне всегда принимаются не-техническими ребятами. Конечно, есть исключения, но они очень редкие. Так вот, то, какие это решения - не является предметом для обсуждения вообще. Мне часто приходится слышать на интервью жалобы на эти самые неправильные решения (я всегда спрашиваю, почему человек уходит из прежней компании). Ребята, это детский сад. Сюда даже не стоит лезть. А фокус, конечно, же не в том, что это за решения, а в том, что происходит дальше - как переключается ответственность на исполнителя. И всё, что вас, друзья бесит - относится не к правильным или неправильным решениям, а к тому, как на вас переключается ответственность за их выполнение.

Таким образом, центральной темой является "запуск". Это справедливо для любой части проекта вплоть до запуска процесса поддержки, если проект не планируется развивать дальше. Любой запуск - запуск всего проекта, его части, отдельного задания - это фактически переключение ответственности с того, кто это самое "запускаемое" придумал на тех, кто это самое "запускаемое" запустит. А теперь давайте попробуем рассмотреть типичный пример этого самого запуска, который всю жизнь существовал в мелких и средних (а, может, и крупных) интернет-компаниях - и наверняка во множестве компаний существует и поныне. Я уже писал об этом ранее, программисты обычно имеют дело с тремя типами документов, из которых по идее они должны реконструировать план работ:
- каракули менеджера, которые последний гордо называет эскизами или концептуальными макетами страниц, где курица лапой нарисованы квадратики, прямоугольнички, стрелочки, полосочки и прочие кружочки.
- то же самое в каком-нибудь экстравагантом формате PSD, который конечно же не открывается на linux'е программиста, и который тот, матерясь, конвертит предварительно в PNG (и делает так при каждом изменении, если самдурак и боится поставить ультиматум не высылать никакие задания в подобных форматах).
- документ под названием "техническое описание", где как правило текстом на языке, похожем на русский, рассказывается о том, какие страницы есть на сайте, что на них показывается и где.

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

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

И тут в голове менеджера загорается два маячка. Во-первых, он понимает, что программист нифига не радеет за бизнес и за результат, и это действительно так. А ещё программист обычно умный, и всячески старается прикрыть свою ленивую жопу - и это тоже действительно так, а те программисты, кто скажет обратное (мол, "а мы не прикрываем!"), либо врут, либо срочно высылайте мне резюме. Во-вторых, этап проектирования - это довольно сложная умственная деятельность, в чем-то схожая с программированием (если быть точнее, с математическим моделированием - вот почему я по-прежнему считаю естественные науки, в особенности физику, не менее важными в образовании программистов, чем математика. если не более). И поскольку это как бы программирование, пусть он сука и программирует. И этот прыщ ещё чота тут диктует? Тумблер включен, счетчик пошел, у тебя столько-то времени - находясь на иерархической лестнице выше, это кажется единственным (признаем, часто весьма действенным) способом "завести" проект в данной ситуации, сдвинуть с мертвой точки, чтобы всё "заеблось" (тоже искусство, кстати, и тема для отдельного поста).

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

Вам, вероятно, кажется, что вещи эти совершенно очевидны. Увы, они настолько же актуальны. Раньше мне было совершенно непонятно, почему так происходит. В молодости я, конечно же считал, что все они пидарасы и просто нихера не умеют работать. Я и сейчас думаю, что отчасти это правда (возможно, вы и сами понимаете, что начальники из бывших программистов никогда не наступят на многие вышеобозначенные грабли). Но есть ещё один момент, куда более важный. Психологический. Из области "борьбы за свою территорию", чтоли. Желание контролировать. Жестко управлять. Заставлять делать по-своему. Мне не хватает знаний из области психологии, чтобы классифицировать, но одно я знаю точно: если вы программист, и это - ваш случай, у вас не останется иного способа взаимодействовать с системой, кроме как принять эти правила игры. Это жизнь. И вы либо втянетесь, либо сбежите назад в угол к своему коду, такому стуктурированному, такому прогнозируемому, легко меняемому и о-боже-какому-же-прекрасному...

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

Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 50 comments