Лента

Основные права разработчика

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

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

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

Но в первую очередь следует убедиться в том, что вы и ваш собеседник правильно понимаете друг друга.

Профессия программиста очень специфична, и объяснить тонкости выполнения той или иной задачи людям, не имеющим технического образования, довольно сложно. Если вы попросите бухгалтера показать, как рассчитывается бюджет, он запросто может упустить что-то крайне важное. Это не означает, что каждый раз нужно проводить собственную техническую экспертизу (все-таки люди других профессий не глупее вас), но определенные сложности в процессе общения будут возникать постоянно. Ваш собеседник должен уяснить, что если его внимание обращают на какие-либо технические трудности, то эти трудности объективно существуют. Мне часто встречались пользователи, которые никак не могли понять, что решить задачу имеющимися средствами не представляется возможным, и не желали мириться с этим. Приходилось вновь и вновь возвращаться к этому вопросу, встречая удивленный и непонимающий взгляд собеседника. Нужно, чтобы менеджер правильно воспринимал вашу техническую терминологию, а вы четко представляли себе, о чем идет речь.

Как составить четкий проект

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

Как составить надежный проект

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

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

Подходящая машина

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

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

Тишина на рабочем месте

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

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

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

Когда не помогают слов

Что делать, если ваш шеф абсолютно не разбирается в компьютерных технологиях и считает совершенно естественным, если температура в комнате с сетевым оборудованием в солнечный день достигает 35 градусов Цельсия? Если вы Джон Эппел, вы сможете объяснить ему, что замена сети и восстановление утраченных данных обойдутся намного дороже, чем установка кондиционера.

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

Руководитель информационной службы той компании считал, что фирме просто не нужны внешние консультанты для установки программного обеспечения, а кроме того, служащим нет необходимости сохранять данные со своих мобильных компьютеров на жесткие диски ПК. В силу вышесказанного он распорядился отключить жесткие диски, чтобы тем самым сократить затраты на техническую поддержку и избавиться от компьютерных вирусов. Этот горе-руководитель, ранее работавший в железнодорожной компании, не мог включить даже собственный ноутбук, утверждая, что администраторы на его предыдущем месте работы использовали для этого Windows NT. «Он не хотел ничего слышать», - вспоминает Эппел, поэтому сотрудники отдела информационных систем попросту игнорировали его бредовые указания.

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

Возьмем, к примеру, администратора электронной почты компании Greyhound Lines. Его руководитель отказывался признать, что потеря сообщений электронной почты может быть вызвана сбоем в сети.

«Когда мы объяснили, что эта проблема связана с системным сбоем или неверными параметрами настройки, он сказал, что такого не могло произойти, и просто нам следует более ответственно относиться к своей работе», - с грустью вспоминает администратор сети.

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

«В последние годы на должность директора по информационным системам в компаниях все чаще назначаются люди с опытом управления в бизнесе», - заметил Фред Маги, вице-президент и директор по исследованиям компании Gartner Group. За последние десять лет соотношение директоров информационных служб, обладающих опытом работы в области информационных технологий, и тех, кто занимался исключительно административной работой, стало 50:50 ( было 80:20).

Хотя и трудно бывает договориться с подобными руководителями-«неспециалистами», существует немало возможностей, позволяющих улучшить рабочие отношения.

Первое, на что следует обратить внимание, - навыки управления, которые диктуются здравым смыслом. «Постарайтесь не раздражаться и не демонстрировать своей враждебности, - советует Эппел. - Поддерживайте профессиональные отношения и не пытайтесь принизить возможности другого человека».

«Разберитесь в ситуации с самого начала, - рекомендует администратор электронной почты компании Greyhound. - Если вовремя этого не сделать - дальше будет намного сложнее. И всегда документально оформляйте всю свою работу».

Каким же образом «образовывать» шефа? По возможности избегайте технического жаргона и для объяснения сложной концепции постарайтесь использовать общеупотребительные термины. Графическое представление - например, простые схемы сети - эффективно при общении с людьми, которые склонны к визуальному восприятию информации. Поразительного эффекта можно добиться, если внимательно отнестись к опыту, пусть даже небольшому, которым обладает ваш собеседник. Нелишне пригласить своего шефа «на экскурсию» в серверную комнату.

Не менее полезно, объясняя технологию, опираться на бизнес-терминологию. Технология, представленная в связи с бизнес-целями вашей компании, будет более понятна вашему шефу и высшему руководству. «Скажите им: «вот сколько мы потеряем, если не будем работать в течение трех дней», - советует Эппел.

«Резюме: придерживайтесь открытости в общении, - утверждает Виктор Даневич, консультант International Network Services, консалтинговой фирмы, специализирующейся на сетевой проблематике. - Очень важно, чтобы ваш шеф понимал, на что вы тратите свое время».

Даневич рекомендует ежедневно предоставлять руководству отчет об электронной почте параллельно со списком тем, которым посвящена корреспонденция.

Постижение основ бизнеса вовсе не сводится к простым разговорам. Директор информационной службы одной из крупных компаний Среднего Запада, продающей устройства связи, утверждает, что он с шефом занимается взаимным обучением.

«Скорее всего, поначалу он не понимал, что такое Asynchronous Transfer Mode, но со временем начал неплохо ориентироваться, - считает этот человек. - Я же проехал вместе с ним по нескольким нашим центрам распространения, так что получил хорошую бизнес-практику».

Вопросы межличностного общения также крайне важны.

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

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

«Как бизнесмену, ему трудно было признать, что жизненный цикл ПК не превышает трех лет. Он всегда рассматривал оборудование как средства, которыми можно пользоваться долгие годы», - отметил директор информационной службы.

Обучение его босса окупилось с лихвой. «Самое главное, что внедрение информационных технологий теперь стали частью планового процесса и стратегическим оружием против конкурентов, а не просто вспомогательным средством», - подчеркнул он.