- PVSM.RU - https://www.pvsm.ru -
Хотелось бы продолжить тему особенностей работы в русских IT-компаниях и высказать свое мнение. Статья будет в некотором роде ответом на статью Основная особенность наших разработчиков [1].
В предыдущей статье был затронут спорный вопрос: а должен ли разработчик заботится о прибыли своей компании или просто хорошо делать свое дело, а о прибылях должны думать другие люди. Большинство текущих разработчиков были рождены в Советском союзе, что, несомненно, наложило свой отпечаток на их ценности. В СССР люди просто делали свою работу и никто (я думаю даже вышестоящее начальство, не говоря уже про инженеров или учителей) не задумывался, а какую именно прибыль приносит его работу. Ну сделал человек на заводе за день 100 втулок, но он не знает ни рыночную цену произведенного товара, ни прибыль, приносимую с продажи этих 100 втулок. В Советском союзе товары могли продаваться ниже себестоимости, это было нормально.
Желание прибыли пришло к нам уже с капиталистическим строем. Молодежь уже адаптируется к новым условиям экономических отношений: дети моют посуду только за iPad’ы, девушки выбирают парня, у которого тачка круче. И нам пытаются привить принцип: все что ни делается, должно делать только ради денег, ради прибыли и сверхприбыли. Но многие рожденные в СССР с этим принципом не согласны. Не могу сказать, что советские люди абсолютно консервативны, но в начале карьеры многие «рожденные в СССР» работают именно за идею, а не ради денег. Потом уже некоторые специалисты начинают понимать, что приносят прибыль своей компании, и тогда уже они начинают требовать увеличение и своей прибыли (зарплаты, премии и других плюшек для себя).
Вот такие получаются 2 стороны медали: с одной стороны программисты могут работать за идею, не думая о прибылях компании, но при этом обычно мало что требуют для себя. С другой стороны человек может работать для увеличения прибыли компании, но при этом он требует некоторую долю этой прибыли для себя. Люди, работающие за идею, обычно идут в программисты. Люди, работающие ради прибыли – в менеджеры. Зарплата менеджера почти всегда выше зарплаты программиста, что подтверждает вышесказанное (менеджер приносит прибыль, но и требует процент от этой прибыли. Программист работает не ради прибыли, ничего не требует для себя, и заплату ему, поэтому, никто не повышает).
Здесь опять затронута особая тема — менеджер против программиста. Это очень широкий вопрос, но один аспект — «взаимодействие менеджера и программиста» — я все-таки затрону. В более широком ключе мои мысли будут касаться не только отношения между программистом и менеджером, но и другие отношения в коллективе: начальник-подчиненный, программист-программист.
Создание программного обеспечения, несомненно, сложный процесс, требующий слаженной работы всего коллектива. В идеале, в этом коллективе каждый должен делать то, что хорошо умеет делать. И при этом стараться не мешать другому делать его работу. Простое, казалось бы, правило в теории. Но на деле все оказывается иначе. Рассмотрим пример:
Пример 0: Вы подходите к разработчику в своей компании и просите его внести очень клёвую штуку в одну программу. Но программист почему-то вашу идею не разделяет, отказывается ее реализовывать. А на ваше давление отвечает, что это сделать нельзя. Вопрос: почему?
Для начала надо выяснить, а кто Вы сами в этой компании и действительно ли этот программист по служебной лестнице ниже Вас и должен реализовывать все Ваши идеи молниеносно. Соблюдение иерархии в компаниях не блажь, а важный принцип. В идеале, давать задания программистам должен только их тим-лидер.
То есть в моем понимании идеальная структура компании: специалисты разбиты на группы по роду деятельности, то есть программисты, занимающиеся разработкой ПО – одна группа. Программисты, занимающиеся созданием рекламного сайта этого ПО – это другая группа. Предположим, есть группа тестеров, и четвертая группа – менеджеров. (Это вариант для примера, разумеется, в реальности и в зависимости от сложности продукта группы могут быть иные). У всех четырех групп есть тим-лидеры, которые представляют всю задачу своего отдела целиком, держат в голове (на бумаге или других носителях информации) все нюансы, они делят задачу на задания, и распределяют эти задания в своей группе. Группы взаимодействуют через своих тим-лидеров. То есть, например, у менеджера появляется идея для улучшения продажи продукта. Он делится этой идеей со своим тим-лидером. Тот оценивают идею, и если она ему нравится – передает идею тим-лидеру отдела разработки. А уже тим-лидер отдела разработки опять оценивают идею, сложность ее реализации и, в случае одобрения идеи, решает кто из его отдела будет её реализовывать. Данная цепочка от идеи до воплощения может показаться длинной, и Вы можете придумать другую структуру. Но какая-то структура отделов и иерархия их (и в них) должна быть. Иначе придет беспорядок и анархия. Представьте, что в коллективе без иерархии к бедному программисту сначала подошел каждый из трех менеджеров со своими идеями, потом коллеги со словами «сделай вот такую фичу, у тебя лучше получиться», а потом еще и начальник придумал грандиозную фичу для разрабатываемой программы. И бедный программист физически не сможет все идеи реализовать. Откажет коллегам — они обидятся, менеджерам — они настучат, а откажет начальнику — тот и вовсе уволить может. Поэтому повторяю, структура внесения идея должна быть обязательно. Это может быть передача идеи через тим-лидера, или как альтернатива, коллективное обсуждение и выбор лучших идей. Но если к программисту подходит коллега или менеджер (то есть кто-то отличный от непосредственного начальника), то я считаю, что программист в праве отказать в реализации этой идеи. Может конечно и реализовать Вашу идею, но не обязан.
Вы тоже не выполняете все требования других людей. Для наглядности разберем примеры:
Пример 1. Ваша теща любит без предупреждения навещать Вас. При чем, каждый раз она требует что-то поменять в Вашей квартире. Вы покупали эту квартиру, Вы делали в ней ремонт. А теперь теща требует повесить цветочную полку в Вашей квартире. Она утверждает, что на полку удобно ставить цветочные горшки, правда у Вас и цветов то дома нет. Но тещу это не смущает, она уверена с полкой квартира будет лучше. Будете ли Вы выполнять требования тещи? Наверняка, нет. Это Ваша квартира, и Вы здесь хозяин. И полка Вам не нужна. Некоторые программисты так же относятся к своим программам. Они считают, что созданная ими программа – их личная собственность, и никто извне не может требовать каких-либо изменений в его программе. Возникает сложная ситуация, надо рассматривать юридическую сторону вопроса. Но обычно, программное обеспечение, разрабатываемое в компании, является собственностью компании. Если это так – то надо эту мысль как-то корректно донести до программиста. Но если авторские права принадлежат программисту, то он в праве сам решать как изменять свою программу.
Пример 2. Ваша теща не унимается с цветочной полкой. На этот раз она просит повещать полку у себя дома. В тещином доме цветочная полка Вам мешать не будет. Но с другой стороны и отсутствие цветочной полки на Вас тоже никак не повлияет. Поэтому вещать полку у тещи или не вещать зависит от многих факторов: есть ли у Вас свободное время, нравится ли Вам теща, сколько усилий у Вас займет данное действие. Вы можете повесить полку (но не обязаны), и это будет одолжением теще. Из этого примера вырисовываются следующие причины отказа:
Другой человек не считает Вашу идею достойной реализации
У него нет времени на реализацию Вашей идеи
У него нет мотивации
Пример 3. Вы решили поработать дома, сидите за компьютером. К Вам подходит жена с желанием помочь Вам.
“Что тут у тебя?” – спрашивает жена
“Да база данных” – отвечаете Вы и на удивленный взгляд жены добавляете – “Таблица сотрудников компании. Мне надо сделать её лучше” – стараетесь на более понятном языке объяснить всё жене.
На что жена отвечает: “Ну, какая-то таблица у тебя не красивая. Можно сделать её симпатичнее, строки с женским персоналом сделать с розовым фоном, а строки с мужским персоналом – синим. А еще для молодых девушек фон сделать ярко-розовым, а для женщин постарше – бледно-розовым. И так же для мужчин. Так будет проще искать сотрудников по полу и по возрасту”.
Вы улыбаетесь на предложение жены. Она хороший учитель рисования в школе, отличная жена. Вы уважаете её за это. Но в Вашей сфере она ничего не понимает. Вы объясняете жене, что заливка фона по цвету не нужна. Если надо найти сотрудников по полу или возрасту есть фильтры. Тогда жена в порыве желания помочь предлагает добавить в таблицу фотографии сотрудников. По ее мнению, это нужно чтобы бухгалтеры узнавали пришедших за зарплатой по фотографии из базы данных. То есть приходит человек за зарплатой, бухгалтер смотрит в базу и по фото находит нужную строку и, соответственно, сумму выдачи. Эту идею Вы тоже считаете неудачной. Но объяснять, почему Вы не будете реализовывать идею очень долго, а у Вас есть другие дела. Поэтому Вы ограничиваетесь коротким: “А это нельзя сделать”. Таким образом, выясняется еще одна причина отказа от реализации чужих идей: отсутствие компетентности советчика.
Пример 4. Вы c дочкой на улице, собираете самодельный квадроцикл. К Вам подходит незнакомая бабушка и говорит: “А что это у Вас девочка возится с машинками? Девочка должна играть в куклы, в машинке ей играть нельзя!” (кстати, реальный случай из нашего двора). И казалось бы, советчик – человек с опытом в воспитании детей (2 дочек и 3 внучек вырастила). Но Вы ее мнения не разделяете. Считаете взгляды бабушки устаревшими и неправильными. Так что наличие программистского опыта не делает Вас отличным советчиком. IT-сфера очень динамична, и Ваши знания и идеи могут быстро устаревать.
Подводя итоги раздела, ответим на вопрос из примера 0.
Программист не реализовывает Ваши идеи по следующим основным причинам:
Большинство данных проблем решится, если структурировать процесс внесения новых предложений. Но у нас это не принято, да и хороших управленцев (кто бы справился с такой задачей) мало. А для решения поставленной задачи надо следующее:
Плохая организация рабочего процесса вредна в любой стране. Но в России организационным вопросам уделяют очень мало внимания, отсюда вытекает множество проблем. В основном мы ждем решения организационных вопросов от менеджеров, от вышестоящего начальства. Но, по сути, внедрить в свою работу систему внесения новых предложений под силу и самим программистам. Если программисты сами начнут пользоваться нужным сервисом, и объяснят другим жаждущим внести свои идеи как этим сервисом пользоваться – то вы решите проблему «множества советчиков». То есть менеджер не будет забегать к вам и вырывать Вас из рабочего потока (как это бывает: Вы программируете, не замечая окружающее, и тут Вас отвлекает менеджер и все ваши мысли уходят, а потом чтобы войти в поток и приступить к программированию нужно время). А так: менеджер внес свое предложение в онлайн-сервис, не мешая Вам. Как у Вас появилось свободное время — Вы зашли на этот сервис и ознакомились с новым предложением. Вы закончили предыдущее задание – заходите на сервис, выбираете лучшую идею и начинаете ее реализовывать. Потому что действительно если говорить «Нет» на все новые идеи, то Вы можете пропустить действительно стоящую и нужную в вашей программе «штуку».
Идея ввода системы для новых предложения не нова и, конечно, рассматривалась другими авторами. Наиболее близка мне интерпретация Стива Макконнелла, описанная им в книге «Совершенный код». Этот автор предлагает записывать все предложения, затем рассматривать их целой группой и выбирать только лучшие. Если мои слова не убедили вас в необходимости системы для новых предложений, то может быть слова такого маститого и уважаемого разработчика и автора книг заставят задуматься над этим вопросов.
Если мой пост убедил Вас в необходимости систематической процедуре контроля предложения, и Вы уже начали задумываться над подходящим инструментом для этой задачи, то могу порекомендовать сервис leankit.com/ [2]. Он реализует мое предложение вносить идеи на стикеты и вещать их на доску. Но при использовании реальных стикером есть небольшие проблемы. Стикеры могут потеряться, надо ходить в кабинет, где висят стикеты, чтобы просмотреть идеи. Сервис leankit.com/ [2] представляет собой сервис веб-стикеров. В комментариях, я думаю, будут добавлены и другие подходящие веб-инструменты.
Автор: sertanta
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/38343
Ссылки в тексте:
[1] Основная особенность наших разработчиков: http://habrahabr.ru/post/185638/
[2] leankit.com/: http://leankit.com/
[3] Источник: http://habrahabr.ru/post/185866/
Нажмите здесь для печати.