Изображение для привлечения внимания. Синтаксис языка программирования выдуманный. Любое совпадение с реально существующим ЯП случайно

Хотелось бы продолжить тему особенностей работы в русских IT-компаниях и высказать свое мнение. Статья будет в некотором роде ответом на статью Основная особенность наших разработчиков.

Рожденный в СССР

В предыдущей статье был затронут спорный вопрос: а должен ли разработчик заботится о прибыли своей компании или просто хорошо делать свое дело, а о прибылях должны думать другие люди. Большинство текущих разработчиков были рождены в Советском союзе, что, несомненно, наложило свой отпечаток на их ценности. В СССР люди просто делали свою работу и никто (я думаю даже вышестоящее начальство, не говоря уже про инженеров или учителей) не задумывался, а какую именно прибыль приносит его работу. Ну сделал человек на заводе за день 100 втулок, но он не знает ни рыночную цену произведенного товара, ни прибыль, приносимую с продажи этих 100 втулок. В Советском союзе товары могли продаваться ниже себестоимости, это было нормально.
Желание прибыли пришло к нам уже с капиталистическим строем. Молодежь уже адаптируется к новым условиям экономических отношений: дети моют посуду только за iPad’ы, девушки выбирают парня, у которого тачка круче. И нам пытаются привить принцип: все что ни делается, должно делать только ради денег, ради прибыли и сверхприбыли. Но многие рожденные в СССР с этим принципом не согласны. Не могу сказать, что советские люди абсолютно консервативны, но в начале карьеры многие «рожденные в СССР» работают именно за идею, а не ради денег. Потом уже некоторые специалисты начинают понимать, что приносят прибыль своей компании, и тогда уже они начинают требовать увеличение и своей прибыли (зарплаты, премии и других плюшек для себя).
Вот такие получаются 2 стороны медали: с одной стороны программисты могут работать за идею, не думая о прибылях компании, но при этом обычно мало что требуют для себя. С другой стороны человек может работать для увеличения прибыли компании, но при этом он требует некоторую долю этой прибыли для себя. Люди, работающие за идею, обычно идут в программисты. Люди, работающие ради прибыли – в менеджеры. Зарплата менеджера почти всегда выше зарплаты программиста, что подтверждает вышесказанное (менеджер приносит прибыль, но и требует процент от этой прибыли. Программист работает не ради прибыли, ничего не требует для себя, и заплату ему, поэтому, никто не повышает).

От каждого по способностям, каждому по потребностям

Здесь опять затронута особая тема — менеджер против программиста. Это очень широкий вопрос, но один аспект — «взаимодействие менеджера и программиста» — я все-таки затрону. В более широком ключе мои мысли будут касаться не только отношения между программистом и менеджером, но и другие отношения в коллективе: начальник-подчиненный, программист-программист.
Создание программного обеспечения, несомненно, сложный процесс, требующий слаженной работы всего коллектива. В идеале, в этом коллективе каждый должен делать то, что хорошо умеет делать. И при этом стараться не мешать другому делать его работу. Простое, казалось бы, правило в теории. Но на деле все оказывается иначе. Рассмотрим пример:
Пример 0: Вы подходите к разработчику в своей компании и просите его внести очень клёвую штуку в одну программу. Но программист почему-то вашу идею не разделяет, отказывается ее реализовывать. А на ваше давление отвечает, что это сделать нельзя. Вопрос: почему?
Для начала надо выяснить, а кто Вы сами в этой компании и действительно ли этот программист по служебной лестнице ниже Вас и должен реализовывать все Ваши идеи молниеносно. Соблюдение иерархии в компаниях не блажь, а важный принцип. В идеале, давать задания программистам должен только их тим-лидер.
То есть в моем понимании идеальная структура компании: специалисты разбиты на группы по роду деятельности, то есть программисты, занимающиеся разработкой ПО – одна группа. Программисты, занимающиеся созданием рекламного сайта этого ПО – это другая группа. Предположим, есть группа тестеров, и четвертая группа – менеджеров. (Это вариант для примера, разумеется, в реальности и в зависимости от сложности продукта группы могут быть иные). У всех четырех групп есть тим-лидеры, которые представляют всю задачу своего отдела целиком, держат в голове (на бумаге или других носителях информации) все нюансы, они делят задачу на задания, и распределяют эти задания в своей группе. Группы взаимодействуют через своих тим-лидеров. То есть, например, у менеджера появляется идея для улучшения продажи продукта. Он делится этой идеей со своим тим-лидером. Тот оценивают идею, и если она ему нравится – передает идею тим-лидеру отдела разработки. А уже тим-лидер отдела разработки опять оценивают идею, сложность ее реализации и, в случае одобрения идеи, решает кто из его отдела будет её реализовывать. Данная цепочка от идеи до воплощения может показаться длинной, и Вы можете придумать другую структуру. Но какая-то структура отделов и иерархия их (и в них) должна быть. Иначе придет беспорядок и анархия. Представьте, что в коллективе без иерархии к бедному программисту сначала подошел каждый из трех менеджеров со своими идеями, потом коллеги со словами «сделай вот такую фичу, у тебя лучше получиться», а потом еще и начальник придумал грандиозную фичу для разрабатываемой программы. И бедный программист физически не сможет все идеи реализовать. Откажет коллегам — они обидятся, менеджерам — они настучат, а откажет начальнику — тот и вовсе уволить может. Поэтому повторяю, структура внесения идея должна быть обязательно. Это может быть передача идеи через тим-лидера, или как альтернатива, коллективное обсуждение и выбор лучших идей. Но если к программисту подходит коллега или менеджер (то есть кто-то отличный от непосредственного начальника), то я считаю, что программист в праве отказать в реализации этой идеи. Может конечно и реализовать Вашу идею, но не обязан.
Вы тоже не выполняете все требования других людей. Для наглядности разберем примеры:
Пример 1. Ваша теща любит без предупреждения навещать Вас. При чем, каждый раз она требует что-то поменять в Вашей квартире. Вы покупали эту квартиру, Вы делали в ней ремонт. А теперь теща требует повесить цветочную полку в Вашей квартире. Она утверждает, что на полку удобно ставить цветочные горшки, правда у Вас и цветов то дома нет. Но тещу это не смущает, она уверена с полкой квартира будет лучше. Будете ли Вы выполнять требования тещи? Наверняка, нет. Это Ваша квартира, и Вы здесь хозяин. И полка Вам не нужна. Некоторые программисты так же относятся к своим программам. Они считают, что созданная ими программа – их личная собственность, и никто извне не может требовать каких-либо изменений в его программе. Возникает сложная ситуация, надо рассматривать юридическую сторону вопроса. Но обычно, программное обеспечение, разрабатываемое в компании, является собственностью компании. Если это так – то надо эту мысль как-то корректно донести до программиста. Но если авторские права принадлежат программисту, то он в праве сам решать как изменять свою программу.
Пример 2. Ваша теща не унимается с цветочной полкой. На этот раз она просит повещать полку у себя дома. В тещином доме цветочная полка Вам мешать не будет. Но с другой стороны и отсутствие цветочной полки на Вас тоже никак не повлияет. Поэтому вещать полку у тещи или не вещать зависит от многих факторов: есть ли у Вас свободное время, нравится ли Вам теща, сколько усилий у Вас займет данное действие. Вы можете повесить полку (но не обязаны), и это будет одолжением теще. Из этого примера вырисовываются следующие причины отказа:
Другой человек не считает Вашу идею достойной реализации
У него нет времени на реализацию Вашей идеи
У него нет мотивации
Пример 3. Вы решили поработать дома, сидите за компьютером. К Вам подходит жена с желанием помочь Вам.
“Что тут у тебя?” – спрашивает жена
“Да база данных” – отвечаете Вы и на удивленный взгляд жены добавляете – “Таблица сотрудников компании. Мне надо сделать её лучше” – стараетесь на более понятном языке объяснить всё жене.
На что жена отвечает: “Ну, какая-то таблица у тебя не красивая. Можно сделать её симпатичнее, строки с женским персоналом сделать с розовым фоном, а строки с мужским персоналом – синим. А еще для молодых девушек фон сделать ярко-розовым, а для женщин постарше – бледно-розовым. И так же для мужчин. Так будет проще искать сотрудников по полу и по возрасту”.
Вы улыбаетесь на предложение жены. Она хороший учитель рисования в школе, отличная жена. Вы уважаете её за это. Но в Вашей сфере она ничего не понимает. Вы объясняете жене, что заливка фона по цвету не нужна. Если надо найти сотрудников по полу или возрасту есть фильтры. Тогда жена в порыве желания помочь предлагает добавить в таблицу фотографии сотрудников. По ее мнению, это нужно чтобы бухгалтеры узнавали пришедших за зарплатой по фотографии из базы данных. То есть приходит человек за зарплатой, бухгалтер смотрит в базу и по фото находит нужную строку и, соответственно, сумму выдачи. Эту идею Вы тоже считаете неудачной. Но объяснять, почему Вы не будете реализовывать идею очень долго, а у Вас есть другие дела. Поэтому Вы ограничиваетесь коротким: “А это нельзя сделать”. Таким образом, выясняется еще одна причина отказа от реализации чужих идей: отсутствие компетентности советчика.
Пример 4. Вы c дочкой на улице, собираете самодельный квадроцикл. К Вам подходит незнакомая бабушка и говорит: “А что это у Вас девочка возится с машинками? Девочка должна играть в куклы, в машинке ей играть нельзя!” (кстати, реальный случай из нашего двора). И казалось бы, советчик – человек с опытом в воспитании детей (2 дочек и 3 внучек вырастила). Но Вы ее мнения не разделяете. Считаете взгляды бабушки устаревшими и неправильными. Так что наличие программистского опыта не делает Вас отличным советчиком. IT-сфера очень динамична, и Ваши знания и идеи могут быстро устаревать.

Основной раздел для тех, кто не захочет читать весь текст

Подводя итоги раздела, ответим на вопрос из примера 0.
Программист не реализовывает Ваши идеи по следующим основным причинам:

1. В компании нет согласованной структуры для внесения новых идей. Поэтому у программиста свобода выбора в реализации (или не реализации новых идей)
2. Программист считает Вас не достаточно компетентным
3. Вы просто не нравитесь программисту (по умолчанию почти все программисты не любят почти всех менеджеров, поэтому если Вы – менеджер, то уважение программистов Вам надо еще заслужить).
4. Отсутствие мотивации. То есть человек получает стабильную зарплату не зависимо от того сделает он вашу фичу или нет. Так зачем ему эту фичу делать? Мотивация премией решило бы этот вопрос
5. У программиста нет времени: он занят другими проектами, или у него могут быть личные дела (жена руку сломала, ребенок заболел и всю ночь не спал и т.п.)
6. Ваша идея не нравится программисту
7. Вашу идею действительно нельзя реализовать

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

1. Разработать и внедрить систему внесения новых предложений. Это может быть веб-ресурс или собственное ПО или в простейшем случае бумажные стикеры. На пример на стикерах можно писать предложение, автора, дату внесения и вешать на доску.
2. Затем нужна система отсева предложений. Потому что Вам ваша идея может казаться гениальной, но нас самом деле никому другому она не понравится. К тому же никогда нельзя реализовать все идеи. Идея – это, предположим, одна строка текса на стикере. А для программиста это часы, а то и дни работы. Ну а сроки сдачи проекта всегда жмут, и иногда не хватает времени на реализацию главного функционала, что уж говорить про дополнительные идеи. Поэтому, как вариант, когда идеи накапливаются — Вы собираете группу людей. Эта группа читает все предложения, обсуждает и выбирает лучшие. У выбранных идей эта же группа может расставить приоритеты, идеи с наивысшим приоритетом реализовываются в первую очередь.
3. Уже после отбора идей тим-лидер или уже сами программисты решают, кто какую идею будет реализовывать. Потому что, во-первых, программист может быть занят другими проектами. Даже если текущий проект с более низким приоритетом человек не может моментально бросить и переключиться на другую задачу. Недописанный код очень опасен. Поэтому все равно необходимо довести до какого-то логического конца текущую работу, прежде чем начать реализовывать новые идеи.

Плохая организация рабочего процесса вредна в любой стране. Но в России организационным вопросам уделяют очень мало внимания, отсюда вытекает множество проблем. В основном мы ждем решения организационных вопросов от менеджеров, от вышестоящего начальства. Но, по сути, внедрить в свою работу систему внесения новых предложений под силу и самим программистам. Если программисты сами начнут пользоваться нужным сервисом, и объяснят другим жаждущим внести свои идеи как этим сервисом пользоваться – то вы решите проблему «множества советчиков». То есть менеджер не будет забегать к вам и вырывать Вас из рабочего потока (как это бывает: Вы программируете, не замечая окружающее, и тут Вас отвлекает менеджер и все ваши мысли уходят, а потом чтобы войти в поток и приступить к программированию нужно время). А так: менеджер внес свое предложение в онлайн-сервис, не мешая Вам. Как у Вас появилось свободное время — Вы зашли на этот сервис и ознакомились с новым предложением. Вы закончили предыдущее задание – заходите на сервис, выбираете лучшую идею и начинаете ее реализовывать. Потому что действительно если говорить «Нет» на все новые идеи, то Вы можете пропустить действительно стоящую и нужную в вашей программе «штуку».

P.S.

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

Автор: sertanta

Источник