Я давно задаю себе вопросы и сам ищу ответы: что такое «идеальная» ИТ-компания? Для застройщика, для менеджера, для владельца, для клиентов? Что такое «хорошая» ИТ-компания, что в ней должно быть, а что нет? В итоге я сформировала для себя этот список, такая себе квинтэссенция желаний и собственного опыта.
Может быть полезно любому разработчику, менеджеру, генеральному директору.
Возможно, это несколько наивно, во многом это более характерно для «неИТ» компаний, но тем не менее… Принципы «идеальной» ИТ компании на мой взгляд. Простыми словами и немного по-детски.
Делайте системы интересными, а вещи качественными («хорошие вещи»)
Вы можете произвести кучу некачественной продукции и в ближайшем будущем заработать на этом больше денег.
Но в долгосрочной перспективе вы проиграете.
Помните, где сейчас пресловутые «дробилки»?.
Исчезли те, кто не успел из них вырасти.
В программировании все то же самое.
Всегда быть на шаг впереди
Не бойтесь пробовать что-то новое.
Попробуй это.
Поиск.
Всегда будьте на острие.
Рано или поздно оно «приведет» вас к чему-то очень интересному и перспективному.
Синергия.
Люди на первом месте Дальше идут технологии, процессы, реклама, контракты, партнёры, деньги, акции и прочая ерунда.
Если ты не веришь людям, а люди не верят тебе, работая за деньги и только за деньги, у тебя нет будущего.
См.
статью Два типа предпринимателей.
Ищите лучших и создавайте командную атмосферу
Ищите лучшее.
Или вырастить лучших.
И платят программистам больше, чем в среднем по рынку.
Придумайте другие бонусы «удержания» — придумайте их.
Создайте свою уникальную атмосферу, в которой людям хотелось бы находиться.
В котором им было бы комфортно.
Никогда не держите вокруг себя «плохих» людей: серых мышей, стукачей, подметателей и прочую шваль – рано или поздно это похоронит и вашу компанию, и вас самих.
Создать комфортные условия труда
Просто поверьте: программист, сидящий на складе среди коробок и полок на шатком стуле, бросит вас при первой же возможности.
Если, конечно, ему в жизни хоть что-то нужно.
Инвестируйте в обучение специалистов
Обучайте самостоятельно, отправляйте на тренинги, курсы, конференции.
Если при этом вы боитесь, что специалист уйдет, «набравшись навыков» на тренингах, значит, в вашей компании более глубокие проблемы.
Решайте их, а не экономьте на обучении.
И не жадничайте! 
Избегайте прямой денежной конкуренции между специалистами
Денежная конкуренция между специалистами – неоспоримое, абсолютное зло.
Денежная конкуренция между сотрудниками приводит к разобщенности коллектива.
Если Вася знает, что сможет «выбить» задание у Пети и заработать в следующем месяце еще 5000, скорее всего, он это сделает. Может быть, Петя даже не обидится.
Но дружить и работать в команде они никогда не будут. Конкуренция может быть «косвенной» — в знаниях, в ответственности, в наставничестве — но не в деньгах.
Это очень плохо.
При этом никакой «выравнивания» быть не должно.
Выбросьте свои старые вещи.
Безжалостный.
Рефакторинг и удаление дерьмового кода, «плохого» кода Старая мебель, серверы и код теснят пространство вокруг.
Они не дают мне дышать.
Делайте генеральную уборку регулярно, и ваш дом станет светлым.
Не идите на поводу у пользователей (клиентов)
Об этом уже написаны тонны литературы; нет смысла повторять.
В ИТ клиент не всегда прав.
Более того, он даже не всегда знает, чего хочет. 
Не позволяйте системе зависать, останавливаться в разработке и расслабляться программистам
Не бойтесь перемен.
Меняйтесь и меняйтесь.
«Встряхните» своих программистов — иначе рано или поздно они расслабятся, высохнут и закостенеют своим пивом — и в какой-то момент уже не смогут делать ничего нового и интересного.
Никогда не делайте ничего быстро.
Это ответит вам позже! Искушение всегда велико.
Но это делает проблемы еще больше.
Вы даже не представляете, что.
Если да, исправьте это «нормально» как можно скорее! 
Программирование – это не про языки!
Программирование — это технологии, среды разработки, API, фреймворки.
Программирование — это люди, их знания и мечты.
Их идеи и стремления.
Языки программирования как сущность вторичны.
SQL: Не пишите сложные хранимые процедуры.
Лучше упростите свои данные и используйте ORM Одна из самых типичных и грубых архитектурных ошибок.
См.
абзац «Никогда не делайте ничего быстро».
Размещайте алгоритмы на серверах приложений, не помещайте алгоритмы в SQL.
SQL SQL отличается.
См.
пункт «Никогда не делай это быстро».
Устраните сложные ветки и условия в своем коде.
Используйте шаблоны .
иначе не узнаешь, где что у тебя есть.
Если условий и ветвей слишком много – это верный звоночек, что в системе что-то «не так», допущены архитектурные ошибки или система просто «переросла» себя и пора что-то кардинально менять.
.
Максимально разделите код на логические и физические объекты.
Если в вашем коде непонятно, за что отвечает объект и от чего он наследуется, вы априори сами уже не знаете, что пишете и что делаете.
Спрашивается: а зачем тогда?.
Ведь по сути мы получаем картину, подобную той, что в известной басне: 
Упрощение приложений.
Забудьте о редактировании значений в сетках Еще одно неистребимое зло, порой приводящее к весьма существенным проблемам в системе.
Каждый раз, когда вы садитесь писать настольное приложение, представьте, что у вас его нет, а есть только веб-интерфейс.
Представьте, как вы будете делать «редактирование картинки в ячейке столбца сетки, являющейся ячейкой другой сетки по такому-то условию» — и вы ужаснетесь.
Вместо всего этого геморроя просто сделайте отдельный редактор.
И не обманывайте себя и клиента.
Не изобретайте велосипед: используйте стандартные решения (лучшие практики, фреймворки и API).
Написать свой алгоритм поиска подстроки в строке, конечно, интересно.
Возможно, он даже будет быстрее стандартного — если вы хороший программист. Проблема в том, что этот алгоритм в большинстве случаев совершенно не нужен.
Гораздо лучше использовать стандартные решения, взяв известный фреймворк, чем увязнуть в изобретении велосипеда.
Не смешивайте разные функции в одну кучу.
Конструктивная (взаимо)заменяемость компонентов (и клиентов) Разработчикам всегда хочется сделать все в одном приложении — зачастую так проще.
Но в конечном итоге вы получите монстра.
Особенно если система большая и сложная.
Не пытайтесь винить в проблемах с производительностью оборудование.
Современный сервер — это здорово.
Но если софт кривоват и съедает всю доступную память, никакой сервер не поможет. Железо все равно выйдет из строя.
Пишите на современных языках программирования и используйте современные технологии.
Конечно, я допускаю, что некоторые люди думают, что писать на Delphi, Visual Basic или каком-то другом странном или древнем диалекте — это круто.
Но это совсем не круто, поверьте.
И в будущем будет много проблем.
Не перегружайте интерфейсы.
Только минималистичный и современный дизайн Попробуйте сделать второе яблоко.
Скорее всего, у вас это не получится.
Но все равно стремитесь.
Список можно расширить – идеальная IT-компания ничем не ограничена!
Теги: #человеческие ресурсы #управление проектами #управление проектами
-
Интернет На Магнитах 1 — Магнит
19 Oct, 24 -
Руссир 2010: Школа Информационного Поиска
19 Oct, 24 -
Впечатления От Angular Connect 2017
19 Oct, 24 -
Илон Маск Откроет Все Патенты Tesla Motors
19 Oct, 24
