Я давно задаю себе вопросы и сам ищу на них ответы: что же есть «идеальная» IT-компания? Для разработчика, для менеджера, для владельца, для клиентов? Что есть «хорошая» IT-компания, что в ней должно быть и чего не должно? В результате для себя я сформировал вот такой вот список, такая квинтэссенция из пожеланий и собственного опыта. Может пригодиться любому разработчику, менеджеру, CEO. Возможно, это и несколько наивно, во многом — более характерно для компаний «не IT», но тем не менее… Принципы «идеальной» IT-компании в моем представлении. Простыми словами и немного по-детски.
Делайте системы интересными, а вещи — качественными («хорошие вещи»)
Можно выпускать кучу некачественных продуктов и в ближайшей перспективе иметь с этого больше денег. Но в дальней перспективе — вы при этом проиграете. Вспомните, где сейчас пресловутые «толкучки»?.. Кто не успел из них вырасти — пропал. В программировании — все то же самое.
Всегда будьте на шаг впереди
Не бойтесь использовать что-то новое. Пробуйте. Ищите. Всегда будьте «на гребне». Рано или поздно это «вывезет» вас к чему-то очень интересному и перспективному.
Синергия. Люди — в первую очередь
Потом уже — технологии, процессы, реклама, контракты, партнеры, деньги, акции и прочая дребедень. Если вы не верите людям, а люди не верят вам, работая ради денег и только ради денег — у вас нет будущего. См. статью Два типа предпринимателей
Ищите лучших и создавайте атмосферу в коллективе
Ищите лучших. Или растите лучших. И платите программистам больше, чем в среднем по рынку. Придумывайте другие «удерживающие» бонусы — изобретайте. Создавайте свою уникальную атмосферу, в которой людям хотелось бы быть. В которой им было бы комфортно. Никогда не держите возле себя «плохих» людей: серых мышек, стукачей, подметал и прочую шушеру — рано или поздно это похоронит и вашу компанию, и вас самих.
Создавайте комфортные условия труда
Просто поверьте: программист, сидящий на складе среди коробок и стеллажей на шатающемся стуле, уйдет от вас при первой же возможности. Если, конечно, ему хоть что-то в жизни надо.
Делайте вложения в обучение специалистов
Обучайте своими силами, отправляйте на тренинги, курсы, конференции. Если вы при этом боитесь, что специалист уйдет, «понабрав скилов» на тренингах — значит, в вашей компании более глубокие проблемы. Решайте их, а не экономьте на обучении. И не жадничайте!
Избегайте прямой денежной конкуренции между специалистами
Денежная конкуренция между специалистами — неоспоримое, абсолютное зло. Денежная конкуренция между сотрудниками приводит к разобщенности коллектива. Если Вася знает, что он может «отбить» задачу у Пети и в следующем месяце заработать на 5000 больше — вероятнее всего, он это сделает. Может быть, Петя даже не обидится… Но дружить и работать как единая команда они уже никогда не будут. Конкуренция может быть «непрямой» — в знаниях, в ответственности, в наставничестве — но только не в деньгах. Это очень плохо. При этом «уравниловки» тоже не должно быть.
Выкидывайте старье. Безжалостно. Делайте рефакторинг и убирайтеговнокод «нехороший» код
Старая мебель, сервера и код стесняют пространство вокруг. Не дают дышать. Делайте генеральную уборку регулярно — и в вашем доме станет светло.
Не идите на поводу у пользователей (клиентов)
Об этом написаны уже тонны литературы, повторяться нет смысла. В IT клиент не всегда прав. Более того — он даже не всегда знает, чего хочет.
Не давайте системе «застыть», разработке остановиться, а программистам — расслабиться
Не бойтесь перемен. Меняйте и меняйтесь. «Встряхивайте» своих программистов — иначе рано или поздно они расслабятся, засохнут и закостенеют со своим пивом — и в какой-то момент не уже смогут сделать ничего нового и интересного.
Никогда не делайте «по-быстрому». Это потом вам еще откликнется!
Соблазн всегда велик. Но проблемы от этого — еще больше. Вы даже не можете себе представить, какие…
Если все же делаете — исправляйте «по-нормальному» как можно скорее!
Программирование — это не языки!
Программирование — это технологии, среды разработки, API, фреймворки. Программирование — это люди, их знания и мечты. Их идеи и стремления. Языки программирования как сущность — вторичны.
SQL: не пишите сложных хранимых процедур. Лучше упрощайте свои данные и используйте ORM
Одна из типичнейших и грубейших архитектурных ошибок. См. пункт «Никогда не делайте „по-быстрому“.
Выносите алгоритмы в сервера приложений, не закладывайте алгоритмы в SQL
SQL SQL'ю рознь. См. пункт „Никогда не делайте “по-быстрому».
Избавляйтесь от сложных ветвлений и условий в коде. Используйте шаблоны
… иначе сами не будете знать где у вас что. Если условий и ветвлений становится слишком много — это верный звоночек, что в системе что-то «не так», что допущены архитектурные ошибки или же система попросту «переросла» себя, и пора что-то менять радикально.
Максимально разделяйте код по логическим и физическим сущностям
Если в вашем коде непонятно за что какой объект отвечает и от чего он наследуется — априори вы сами уже не знаете что вы пишете и чем вообще занимаетесь. Спрашивается: нафига тогда?.. Ведь по-сути получаем картинку как в известной басне:
Упрощайте приложения. Забудьте про редактирование значений в гридах
Еще одно неискоренимое зло, порой приводящее к очень значительным проблемам в системе. Всякий раз, садясь писать десктопное приложение — представьте, что у вас его нет, а есть только web-интерфейс. Представьте как вы там будете делать «редактирование картинки в ячейке колонки грида, которая является ячейкой другого грида по условию такому-то» — и ужаснитесь. Вместо того, чтобы иметь весь этот геморрой — просто сделайте отдельный редактор. И не парьте себе и заказчику мозг.
Не изобретайте велосипеды: используйте стандартные решения (Best Practices, фреймворки и API)
Написать свой алгоритм поиска подстроки в строке — конечно, интересно. Может быть, он даже будет быстрее стандартного — если вы хороший программист. проблема заключается в том, что этот алгоритм в большинстве случаев — абсолютно не нужен. Гораздо оптимальнее — воспользоваться стандартными решениями, взяв известный фреймворк, чем погрязнуть в изобретении велосипедов.
Не смешивайте разный функционал в одну кучу. Проектируйте (взаимо)заменяемость компонентов (и клиентов)
У разработчиков всегда велик соблазн сделать все в одном приложении — зачастую так проще. Но в перспективе — получите монстра. Особенно если система большая и сложная.
Не пытайтесь возложить проблемы производительности на железо
Суперсовременный сервер — это отлично. Но если ПО кривое и жрет всю память, какая есть в наличии — никакой сервер не поможет. Железо все равно подведет.
Пишите на современных языках программирования и используйте современные технологии
Я, конечно, допускаю, что кому-то чудится, будто писать на Delphi, Visual Basic или каком-нибудь другом странном или старинном диалекте — это круто. Но это совсем не круто, поверьте. А проблем в перспективе будет очень много.
Не перегружайте интерфейсы. Только минималистичный и современный дизайн
Пытайтесь сделать вторую Apple. Скорее всего, у вас не получится. Но все равно стремитесь.
Список можно дополнять — идеальная IT-компания ничем не ограничивается!
Делайте системы интересными, а вещи — качественными («хорошие вещи»)
Можно выпускать кучу некачественных продуктов и в ближайшей перспективе иметь с этого больше денег. Но в дальней перспективе — вы при этом проиграете. Вспомните, где сейчас пресловутые «толкучки»?.. Кто не успел из них вырасти — пропал. В программировании — все то же самое.
Всегда будьте на шаг впереди
Не бойтесь использовать что-то новое. Пробуйте. Ищите. Всегда будьте «на гребне». Рано или поздно это «вывезет» вас к чему-то очень интересному и перспективному.
Синергия. Люди — в первую очередь
Потом уже — технологии, процессы, реклама, контракты, партнеры, деньги, акции и прочая дребедень. Если вы не верите людям, а люди не верят вам, работая ради денег и только ради денег — у вас нет будущего. См. статью Два типа предпринимателей
Ищите лучших и создавайте атмосферу в коллективе
Ищите лучших. Или растите лучших. И платите программистам больше, чем в среднем по рынку. Придумывайте другие «удерживающие» бонусы — изобретайте. Создавайте свою уникальную атмосферу, в которой людям хотелось бы быть. В которой им было бы комфортно. Никогда не держите возле себя «плохих» людей: серых мышек, стукачей, подметал и прочую шушеру — рано или поздно это похоронит и вашу компанию, и вас самих.
Создавайте комфортные условия труда
Просто поверьте: программист, сидящий на складе среди коробок и стеллажей на шатающемся стуле, уйдет от вас при первой же возможности. Если, конечно, ему хоть что-то в жизни надо.
Делайте вложения в обучение специалистов
Обучайте своими силами, отправляйте на тренинги, курсы, конференции. Если вы при этом боитесь, что специалист уйдет, «понабрав скилов» на тренингах — значит, в вашей компании более глубокие проблемы. Решайте их, а не экономьте на обучении. И не жадничайте!
Избегайте прямой денежной конкуренции между специалистами
Денежная конкуренция между специалистами — неоспоримое, абсолютное зло. Денежная конкуренция между сотрудниками приводит к разобщенности коллектива. Если Вася знает, что он может «отбить» задачу у Пети и в следующем месяце заработать на 5000 больше — вероятнее всего, он это сделает. Может быть, Петя даже не обидится… Но дружить и работать как единая команда они уже никогда не будут. Конкуренция может быть «непрямой» — в знаниях, в ответственности, в наставничестве — но только не в деньгах. Это очень плохо. При этом «уравниловки» тоже не должно быть.
Выкидывайте старье. Безжалостно. Делайте рефакторинг и убирайте
Старая мебель, сервера и код стесняют пространство вокруг. Не дают дышать. Делайте генеральную уборку регулярно — и в вашем доме станет светло.
Не идите на поводу у пользователей (клиентов)
Об этом написаны уже тонны литературы, повторяться нет смысла. В IT клиент не всегда прав. Более того — он даже не всегда знает, чего хочет.
Не давайте системе «застыть», разработке остановиться, а программистам — расслабиться
Не бойтесь перемен. Меняйте и меняйтесь. «Встряхивайте» своих программистов — иначе рано или поздно они расслабятся, засохнут и закостенеют со своим пивом — и в какой-то момент не уже смогут сделать ничего нового и интересного.
Никогда не делайте «по-быстрому». Это потом вам еще откликнется!
Соблазн всегда велик. Но проблемы от этого — еще больше. Вы даже не можете себе представить, какие…
Если все же делаете — исправляйте «по-нормальному» как можно скорее!
Программирование — это не языки!
Программирование — это технологии, среды разработки, API, фреймворки. Программирование — это люди, их знания и мечты. Их идеи и стремления. Языки программирования как сущность — вторичны.
SQL: не пишите сложных хранимых процедур. Лучше упрощайте свои данные и используйте ORM
Одна из типичнейших и грубейших архитектурных ошибок. См. пункт «Никогда не делайте „по-быстрому“.
Выносите алгоритмы в сервера приложений, не закладывайте алгоритмы в SQL
SQL SQL'ю рознь. См. пункт „Никогда не делайте “по-быстрому».
Избавляйтесь от сложных ветвлений и условий в коде. Используйте шаблоны
… иначе сами не будете знать где у вас что. Если условий и ветвлений становится слишком много — это верный звоночек, что в системе что-то «не так», что допущены архитектурные ошибки или же система попросту «переросла» себя, и пора что-то менять радикально.
Максимально разделяйте код по логическим и физическим сущностям
Если в вашем коде непонятно за что какой объект отвечает и от чего он наследуется — априори вы сами уже не знаете что вы пишете и чем вообще занимаетесь. Спрашивается: нафига тогда?.. Ведь по-сути получаем картинку как в известной басне:
Упрощайте приложения. Забудьте про редактирование значений в гридах
Еще одно неискоренимое зло, порой приводящее к очень значительным проблемам в системе. Всякий раз, садясь писать десктопное приложение — представьте, что у вас его нет, а есть только web-интерфейс. Представьте как вы там будете делать «редактирование картинки в ячейке колонки грида, которая является ячейкой другого грида по условию такому-то» — и ужаснитесь. Вместо того, чтобы иметь весь этот геморрой — просто сделайте отдельный редактор. И не парьте себе и заказчику мозг.
Не изобретайте велосипеды: используйте стандартные решения (Best Practices, фреймворки и API)
Написать свой алгоритм поиска подстроки в строке — конечно, интересно. Может быть, он даже будет быстрее стандартного — если вы хороший программист. проблема заключается в том, что этот алгоритм в большинстве случаев — абсолютно не нужен. Гораздо оптимальнее — воспользоваться стандартными решениями, взяв известный фреймворк, чем погрязнуть в изобретении велосипедов.
Не смешивайте разный функционал в одну кучу. Проектируйте (взаимо)заменяемость компонентов (и клиентов)
У разработчиков всегда велик соблазн сделать все в одном приложении — зачастую так проще. Но в перспективе — получите монстра. Особенно если система большая и сложная.
Не пытайтесь возложить проблемы производительности на железо
Суперсовременный сервер — это отлично. Но если ПО кривое и жрет всю память, какая есть в наличии — никакой сервер не поможет. Железо все равно подведет.
Пишите на современных языках программирования и используйте современные технологии
Я, конечно, допускаю, что кому-то чудится, будто писать на Delphi, Visual Basic или каком-нибудь другом странном или старинном диалекте — это круто. Но это совсем не круто, поверьте. А проблем в перспективе будет очень много.
Не перегружайте интерфейсы. Только минималистичный и современный дизайн
Пытайтесь сделать вторую Apple. Скорее всего, у вас не получится. Но все равно стремитесь.
Список можно дополнять — идеальная IT-компания ничем не ограничивается!