Pull to refresh

Правила «хорошей» IT-компании

Reading time 5 min
Views 18K
Я давно задаю себе вопросы и сам ищу на них ответы: что же есть «идеальная» IT-компания? Для разработчика, для менеджера, для владельца, для клиентов? Что есть «хорошая» IT-компания, что в ней должно быть и чего не должно? В результате для себя я сформировал вот такой вот список, такая квинтэссенция из пожеланий и собственного опыта. Может пригодиться любому разработчику, менеджеру, CEO. Возможно, это и несколько наивно, во многом — более характерно для компаний «не IT», но тем не менее… Принципы «идеальной» IT-компании в моем представлении. Простыми словами и немного по-детски.





Делайте системы интересными, а вещи — качественными («хорошие вещи»)

Можно выпускать кучу некачественных продуктов и в ближайшей перспективе иметь с этого больше денег. Но в дальней перспективе — вы при этом проиграете. Вспомните, где сейчас пресловутые «толкучки»?.. Кто не успел из них вырасти — пропал. В программировании — все то же самое.



Всегда будьте на шаг впереди

Не бойтесь использовать что-то новое. Пробуйте. Ищите. Всегда будьте «на гребне». Рано или поздно это «вывезет» вас к чему-то очень интересному и перспективному.



Синергия. Люди — в первую очередь

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



Ищите лучших и создавайте атмосферу в коллективе

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



Создавайте комфортные условия труда

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



Делайте вложения в обучение специалистов

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



Избегайте прямой денежной конкуренции между специалистами

Денежная конкуренция между специалистами — неоспоримое, абсолютное зло. Денежная конкуренция между сотрудниками приводит к разобщенности коллектива. Если Вася знает, что он может «отбить» задачу у Пети и в следующем месяце заработать на 5000 больше — вероятнее всего, он это сделает. Может быть, Петя даже не обидится… Но дружить и работать как единая команда они уже никогда не будут. Конкуренция может быть «непрямой» — в знаниях, в ответственности, в наставничестве — но только не в деньгах. Это очень плохо. При этом «уравниловки» тоже не должно быть.



Выкидывайте старье. Безжалостно. Делайте рефакторинг и убирайте говнокод «нехороший» код

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



Не идите на поводу у пользователей (клиентов)

Об этом написаны уже тонны литературы, повторяться нет смысла. В IT клиент не всегда прав. Более того — он даже не всегда знает, чего хочет.



Не давайте системе «застыть», разработке остановиться, а программистам — расслабиться

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



Никогда не делайте «по-быстрому». Это потом вам еще откликнется!

Соблазн всегда велик. Но проблемы от этого — еще больше. Вы даже не можете себе представить, какие…
Если все же делаете — исправляйте «по-нормальному» как можно скорее!



Программирование — это не языки!

Программирование — это технологии, среды разработки, API, фреймворки. Программирование — это люди, их знания и мечты. Их идеи и стремления. Языки программирования как сущность — вторичны.



SQL: не пишите сложных хранимых процедур. Лучше упрощайте свои данные и используйте ORM

Одна из типичнейших и грубейших архитектурных ошибок. См. пункт «Никогда не делайте „по-быстрому“.



Выносите алгоритмы в сервера приложений, не закладывайте алгоритмы в SQL

SQL SQL'ю рознь. См. пункт „Никогда не делайте “по-быстрому».



Избавляйтесь от сложных ветвлений и условий в коде. Используйте шаблоны

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



Максимально разделяйте код по логическим и физическим сущностям

Если в вашем коде непонятно за что какой объект отвечает и от чего он наследуется — априори вы сами уже не знаете что вы пишете и чем вообще занимаетесь. Спрашивается: нафига тогда?.. Ведь по-сути получаем картинку как в известной басне:



Упрощайте приложения. Забудьте про редактирование значений в гридах

Еще одно неискоренимое зло, порой приводящее к очень значительным проблемам в системе. Всякий раз, садясь писать десктопное приложение — представьте, что у вас его нет, а есть только web-интерфейс. Представьте как вы там будете делать «редактирование картинки в ячейке колонки грида, которая является ячейкой другого грида по условию такому-то» — и ужаснитесь. Вместо того, чтобы иметь весь этот геморрой — просто сделайте отдельный редактор. И не парьте себе и заказчику мозг.



Не изобретайте велосипеды: используйте стандартные решения (Best Practices, фреймворки и API)

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



Не смешивайте разный функционал в одну кучу. Проектируйте (взаимо)заменяемость компонентов (и клиентов)

У разработчиков всегда велик соблазн сделать все в одном приложении — зачастую так проще. Но в перспективе — получите монстра. Особенно если система большая и сложная.



Не пытайтесь возложить проблемы производительности на железо

Суперсовременный сервер — это отлично. Но если ПО кривое и жрет всю память, какая есть в наличии — никакой сервер не поможет. Железо все равно подведет.



Пишите на современных языках программирования и используйте современные технологии

Я, конечно, допускаю, что кому-то чудится, будто писать на Delphi, Visual Basic или каком-нибудь другом странном или старинном диалекте — это круто. Но это совсем не круто, поверьте. А проблем в перспективе будет очень много.



Не перегружайте интерфейсы. Только минималистичный и современный дизайн

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



Список можно дополнять — идеальная IT-компания ничем не ограничивается!
Tags:
Hubs:
-20
Comments 8
Comments Comments 8

Articles