Comments 47
Что касается гребцов, то да, мы все гребцы, в принципе-то. Абсолютно все: и мы гребём за деньги, которые нам нужны, и приносим деньги тем, на кого гребём. И гребут все: гугловцы, эппловцы и сотрудники Space X.
Но я транслирую мысль о том, что нужно всегда оставаться человеком, находить свои плюсы и тогда будет в разы проще. Потому что сплетники в курилке и бегуны по трудовым инспекциям выглядят невыигрышно по сравнении с уверенными в себе профессионалами. Надо ли менять работу? Надо! Надо ли уходить, если вас унизили? Почти всегда однозначно! Но всегда нужно думать, в чём причина, не в одном лишь ЧСВ. Это если коротко.
По большому счету, если отправить директора, бухгалтера, маркетолога на 3-месячные курсы, то худо-бедно, они смогут заменить токаря, сварщика, слесаря начальных разрядов.Этим вы отдельно доставили. Realy? Давайте писать в минобр, отменим техникумы. Вы же понимаете, как сегодня работают на заводах? Станки с ЧПУ, автоматизация, характеристики металлов, вот это всё…
Коллега, спасибо за ответ.
А вот это что?
В этом комментарии вы написали:
Увы, приходилось. Двоих. Увольняла как руководитель отдела. Я не самая сентиментальная девушка, но они мне снятся до сих пор, а при встрече я отвожу глаза. Хотя увольняли их за низкие показатели и взяли чудо-мальчика, который перепахал половину работы отдела.
Если я ошибся, и это две разные истории, то ваши рассказы тем более не в вашу пользу:
получается, у вас тиражируется ситуация, когда к вам приходит горячий выпускник, и вы его выделяете на фоне опытных сотрудников за стахановские методы.
То, что в одном случае вы уволили сотрудников, а в другом нет — детали, не меняющие сути.
А суть в том, что, по вашим статьям и комментариям, получается, вы даже не понимаете, чем чреваты аврально-геройские методы работы в одиночку.
- В первом случае речь о тестировщике, который «сделал» тимлидов, но никто уволен не был. Парень через 2 года просто нашёл работу за рубежом, сильно у нас прокачавшись.
- А вот уволенные — это маркетологи. И мальчика взяли ПОТОМ. Работает до сих пор.
вы даже не понимаете, чем чреваты аврально-геройские методы работы в одиночкуСменой нескольких работ со скандалом как минимум.
Прекратите заниматься следствием и софистикой, ваши аргументы пока совершенно несостоятельны. Расскажите про прекрасную командную работу, которая реально случилась вне пределов влажных мечтаний.
Что касается гребцов, то да, мы все гребцы, в принципе-то.
За это отдельное спасибо.
Как говорить "гребцы", "у станка" именно про разработчиков — всегда пожалуйста.
А как обоснованное возмущение в ответ, так сразу "ну что вы, что вы, мы ж все по сути, фигурально выражаясь, гребцы и у станка стоим"..
Коллега, пожалуйста, придерживайтесь норм корректного общения.
И если моя статья вас как то задела (а, значит, в любом случае, показалось интересной), то прочтите еще раз — это не разгром ваших статей по пунктам, а полемическая статья об актуальных проблемах, навеянная вашими двумя статьями.
Хотя и построенная в форме ответа, т.к. изначально я задумывал написать комментарий-ответ, а получилась статья.
В своей статье я написал о том, что в последнее время про разработчиков принято говорить "гребцы", "стоите у станка", в т.ч. в глаза со стороны "менеджмента"
бегуны по трудовым инспекциям
Это вы так изящно назвали людей, которые не боятся отстаивать свои права и/или права своих коллег?
Мммм.
выглядят невыигрышно по сравнении с уверенными в себе профессионалами
То есть, уверенный в себе профессионал — это тот, кто не пойдет в трудовую инспекцию?
Ммммм.
уверенный в себе профессионал — это тот, кто не пойдет в трудовую инспекциюСтучать по надуманному поводу — нет, конечно. Увы, это не всегда увязано с отстаиванием прав (я приводила пример про сотрудника, который пожаловался на переработку, когда руководитель попросил его отвезти к клиенту после работы).
И да, случай с огнетушителем был абсолютно корректным, эта штука предназначена для спасения жизни, а с этим не шутят.
Знаете, думается это был не первый подобный случай, вряд ли бы с первого раза он начал эскалировать этот вопрос. Скорее это такой common practice.
К тому же — он же не водителем не нанимался. Да и рабочий день уже закончился.
С какого перепуга он должен свое личное время тратить?
Он что то с этого получит — финансовую компенсацию, возможность на следующий день придти к обеду, выбор делать или нет в конце концов?
У компании нет денег на такси?
Я вот тоже допустим частенько занимаюсь рабочими делами после окончания официального рабочего дня, так как большая часть моей команды на западном побережье США.
Но во-первых, к меня есть выбор делать это или нет (и никто меня осуждать не будет если меня вдруг не будет в это время на связи, а если я ну очень нужен — все будет запланировано на максимально ранее время и сильно заранее будет задан вопрос "сможешь ли"?), во-вторых если я знаю, что вечером придется задержаться, то я просто могу придти позже и это тоже нормально. Да и в целом отношения здоровые в коллективе, никто не будет тебя как такси использовать, дороговато обходится такой таксист.
Отношения работника и работодателя должны быть партнёрские, причем с обоих сторон. Нужно уметь договариваться и создавать условия устраивающие обоих. И уж точно не надо пытаться повесить на человека задачу, которая к нему не относится ну совершенно никак.
Аналитика — если не легко, но нетрудно. Ибо частью курса обучения разработчика как раз и является исследование предметной области, постановка задачи и моделирование.
А немодное нынче ООП — так и вовсе именно про "это".
Нормального аналитика — не сможет. Аналитик это все-таки про сведение фактов, непротиворечивость требований, кучу переговоров и все прочее. Очень малая часть программистов владеет такими навыками.
ПМ'а? Ну, если разработчик более-менее умеет смотреть на задачи "сверху", более-менее коммуникабелен и в целом дружит с головой, то, если нет опыта, то с трудом, с меньшим качеством, но сможет.
Так же — не сможет. ПМ это довольно большое количество огранизационных вопросов, в том числе и всякие аджайлы. Посмотрите на топики на хабре, большое количество программистов даже не понимает, чем плох waterflow, потому что они его в целом не застали, но зато готовы во всю хейтить гибкие методологии, хотя тоже нормальной реализации не застали.
Ну и да, я просто оставлю ссылку на свой комментарий. Среди разработчиков софта нет инженеров, потому что научной базы, которая пересекается с прикладной разработкой практически нет.
Насчет ПМ тут все таки зависит не от того, программист ты или нет, а скорее от твоих софт скиллов. В большинстве своем программисты не полюбят работу ПМ-ом. Но также встречается куча ситуаций, когда программисты становятся отличными ПМ-ами. Технический бекграунд полезен везде.
Насчет отсутствия научной базы и вашего комментария. Ну, тут я с вами не соглашусь. Я конечно согласен, что сейчас порог входа в программирование снизили до ужаса, и буквально любой человек может накидать свой сайт, но. Давайте взглянем на более сложные ПО, где мало того, что там должна быть продуманна архитектура, так еще и оптимизации, с учетом железа и прочее. А еще, во многих программах используют плавающую арифметику, что само по себе отдельная наука. Также дискретная математика присутствует во всем программировании, куда бы вы от этого не пытались убежать. Опять же, все сильно зависит от ситуции. Если мы говорим про клепание сайтов на вордпрессе или чем еще, либо про написание какой-то банальной нейросети по гайду, не понимая, что это вообще такое с точки зрения математической модели, то да. Но это ведь не программирование виновато, а люди, которые не хотят учиться.
Насчет ПМ тут все таки зависит не от того, программист ты или нет, а скорее от твоих софт скиллов. В большинстве своем программисты не полюбят работу ПМ-ом. Но также встречается куча ситуаций, когда программисты становятся отличными ПМ-ами. Технический бекграунд полезен везде.
Что собственно говоря означает, что не всякий программист сможет заменить ПМа.
Насчет отсутствия научной базы и вашего комментария. Ну, тут я с вами не соглашусь. Я конечно согласен, что сейчас порог входа в программирование снизили до ужаса, и буквально любой человек может накидать свой сайт, но. Давайте взглянем на более сложные ПО, где мало того, что там должна быть продуманна архитектура, так еще и оптимизации, с учетом железа и прочее. А еще, во многих программах используют плавающую арифметику, что само по себе отдельная наука. Также дискретная математика присутствует во всем программировании, куда бы вы от этого не пытались убежать. Опять же, все сильно зависит от ситуции. Если мы говорим про клепание сайтов на вордпрессе или чем еще, либо про написание какой-то банальной нейросети по гайду, не понимая, что это вообще такое с точки зрения математической модели, то да. Но это ведь не программирование виновато, а люди, которые не хотят учиться.
Назовите, пожалуйста, научные дисциплины, которые вы используете при разрабатывании приложения. Ну и нет так, что бы "используется плавающая арифметика — вот это и наука", а вот именно "я использую математические модели из математического анализа" ну или что-то похожее.
Например, при проектировании зданий, деталей и прочего инженеры используют сопромат. При разрабатывании очередного веб-приложения программист использует в основном свои знания про программирование, а не какой-то computer science, потому что он бесполезен для этого.
Ну и да, оптимизация под железо — звучит закшварно.
Но если заказчиков не один, или требования полугодовой давности противоречат текущим требованиям. Да еще и исходят от разных людей. Тут для программиста ближе подход — запилим по более новым требованиям, а там посмотрим. Далеко не всегда такой подход допустим.
Забавно рассуждать о непонимании waterfall, называя его waterflow.
Из разработчиков чаще всего приходят такие позиции. Идут туда в силу «взросления» или когда перестают быть разработчиками. У нас вообще мало кто из разработчиков до пенсии дорабатывает, многие уходят в «смежные» профессии.
Разве у нас достаточно ВУЗов, которые готовят аналитиков и PM?
Разве у нас достаточно вузов, которые готовят программистов? В Украине какого-то нормального вуза прямо с программистким образованием я не знаю, в основном это какая-то похожая профессия с кучей всего подряд. У меня вот специальность называлась системный анализ, а я взял и пошел в программисты.
Ну и да, когда я говорю о том, что разработчики не могут заменить вышеназванных, подразумевается, что далеко не каждый разработчик может заменить вышеназванных. Какие-то ПМ и аналитики вырастают из программистов, какие-то приходят из смежных областей (ПМ то менеджер, а вот менеджеров у нас готовят как пирожки). И кто лучше на позиции ПМ — бывший технарь или бывший обычный менеджер — это пока еще открытый вопрос, к сожалению.
Это про про то, что все эти модные в последние годы разговоры о "гребцах", "разработчиков у станка" — вот это как раз системная попытка принизить роль разработчиков.
все уйдут в QA, аналитики, ПМ'ы, а в разработчики никто не захочет идти (да и некому уже будет).
Именно этим на мой взгляд и объясняется отсутствие до сих пор по настоящему жизнеспособной и по-настоящеме отечественной операционной системы.
Следуя этой логике, то ничего нового не надо. Хотя почему-то еще древние греки поддерживали тауку и технику. И почему обязательно за деньги? Можно за перспективу, вот только бы быть уверенным в перспективе.
И почему обязательно за деньги? Можно за перспективуБесплатно я и сам могу пилить в месяц по 100 строк. Лет через 20 — сделаю. А может, и не сделаю.
Конечно не сделаете — у вас нет перспективы! Вы не знаете зачем!
Как вы оцениваете её перспективы?
Развитие «Колибри» шло довольно быстро вплоть до 2009 года.
Современная «Колибри» — это регулярно обновляемые «ночные сборки» последней официальной версии, вышедшей в конце 2009 года
Этим все сказано. Это бич всех так называемых отечесивенных ОС — объявятся. я так понимаю поставятся куда-то и на этом их развитие кончается. Если говорить про KalibriOS — замечательная ОС для использования в учебном процессе аналагично ОС Minix.
объявятся. я так понимаю поставятся куда-то и на этом их развитие кончаетсяЛогично. Потому что финансирования нет. Энтузиаст может год работать, три, или пять. Но в конце концов ему надоест и он найдёт себе новый проект.
Возможен вариант самоподдержания процесса, когда новые люди приходят взамен ушедших, но чаще они приходят, чтобы переписать как им нравится, а не поддерживать чужой старый код, обросший костылями.
Но если государство ставить задачу иметь отечественную ОС, то оно должно и задуматься о том как эта ОС будет поддерживаться и развиваться. Это как с критически важными техлогиями. Представьте себе поддержку атомной электростанции.
системная попытка принизить роль разработчиков
Здравствуйте, я из эксплуатации, и Вы мне этой фразой делаете очень смешно. Именно я Вам буду снизу стучать, когда в процессе принижения роли разработчика будет достигнуто «дно».
Отчего-то сравниваемый разработчик и коммуникабелен, и тесты пишет сам, и даже на разработчика обучался. Может быть, в Вашей эпсилон-окрестности это справедливо для любого разработчика, и коль так, я за Вашу окрестность очень рад. В моей же эпсилон-окрестности разработчики в массе своей средние. По сторонам не смотрят, смежных областей знать не желают, как устроен программируемый ими компьютер — не ведают.
«Мы бизнес-логику пишем, деньги вам всем зарабатываем» — говорят такие разработчики. А мы вашу бизнес-логику потом подпираем энтерпрайз-рестартом раз в день или даже в час, потому что два дня/часа без деградации оно работать не в состоянии.
Посему предлагаю не сравнивать верхние 20% разработчиков со всеми QA/PM/аналитиками, нечестное какое-то сравнение выходит.
Ах да, совсем забыл про вас, спасибо, что напомнили.
В кучку QA/PM/аналитиков (в противовес разработчикам в контексте статьи) нужно добавить модное словечко последней пары лет — DevOps ("эксплуатация").
То, что по вашим словам, в вашей эпсилон окрестности разработчики средние, которые пишут приложения, которые вам приходится, по вашим словам, перезапускать раз в сутки или даже раз в час, как раз — уже появившиеся плоды системы, в которой роль разработки принижена (неадекватно сути разработки и тому, какую роль она выполняет (должна выполнять) в общем процессе).
Именно об этом моя статья.
Вы вообще в курсе, что слышат верхние 20% разработчиков, когда говорят "менеджерам", что знают, как писать приложения, чтобы вам не приходилось перезапускать их раз в час?
DevOps («эксплуатация»)
Девопс и эксплуатация — это разные сущности. Особенно, если это эксплуатация не только и не столько более-менее стандартных linux-серверов, а какого-нибудь вендорского железа или вендорского софта.
Я вообще в курсе. Я также в курсе, что вот этот мифический разработчик из статьи, коль скоро он в состоянии заменить ПМа, найдёт способ сделать так, как нужно (лесть, уговоры, угрозы, шантаж; партизанщина тоже неплохо заходит).
Ваша статья, как мне видится, о том, что «как вы посмели вообще покуситься на элиту ИТ», причём элитарность определяется по должности в трудовой книжке, а не по качествам конкретного человека. И тем не менее всех не подходящих под элитарность программистов Вы объявляете некачественными, плодами злобной системы. Ссылаетесь на исследования коллег без ссылок на статьи с описанием этих исследований, занимаетесь шапкозакидательством «за три месяца [любой] бухгалтер разберётся в металлообработке».
«Относитесь к нам с должным почтением, и мы вам построим город-сад». Не построите, к сожалению, хоть контейнеровоз почтения на вас вывали.
Тестировщика — легко.
Составить тест-кейсы для своего кода, все «прокликать» и написать автотесты.
Тем более, что юнит- и интеграционные тесты разработчик все равно пишет.
… категорически не согласен.
По крайней мере, с легко и тем более.
1. Юнит-тесты — это скорее повинность.
2. Интеграционные тесты — это скорее формальность.
3. Все «прокликать» по написанному тест-кейсу (не говоря уже об автотесте) — мягко говоря не самая тривиальная задача
Может, я вырос как тестировщик в неблагополучном районе, не познал настоящей жизни и ненарочно умаливаю способности разработчиков…
И если типовой разработчик из вашего сферического вакуума таки может, то это скорее чудо-мальчик, упомянутый гражданочкой-оппонентом. Тогда непонятна суть вашего спора, ведь его можно декомпозировать еще на один уровень и доказывать, что тестировщик — тоже инженер
Более того, разработчику полезно и нужно уметь в токаря и слесаря, т.к. это помогает пространственному мышлению (в дополнение к разработческому абстрактному) + мелкая работа руками.
Все это помогает сохранять и развивать интеллект (в т.ч. и «разработческий») и образовывать новые нейронные связи.
В этом смысле это так же актуально, как изучение иностранных языков или языков программирования с принципиально новой парадигмой.
А когда попросят Фронтенд на Реакте/Ангуляре писать, да БЭМ использовать сказать: «Нет, извините, не знаю таких, пока что на чтении про Си, Кернигана и Ритчи остановился»?
Нет, я конечно понимаю что хорошо бы изучать предметную, и смежные области, не ограничивать себя рамками одной парадигмы программирования. Однако, мне кажется, вот это вот «программист должен» слишком часто доходит до абсурда.
При всем уважении, токарному делу обучится — надо только прослушать курс (есть теоретическая база), а затем несколько лет тренировать руки под однотипные операции. Тогда да, будешь токарем первой категории, ну или станок купить.
С программистами такого же не замечал, сидит человек годами, а как писал говнокод, так и продолжает. Купить станок не поможет, потому что задачу автоматизации по какой-то причине до сих пор не смогли автоматизировать. Правда не ясно кто будет заниматься автоматизацией автоматизации процессов. Неужели программисты?
К тому же, выточить нужную деталь можно многократно меньшим количеством возможных последовательностей базовых действий. Даже обработка кнопки ОК в диалоге делается разными способами, хотя сама по себе она является базовым действием в рамках UI.
А теперь представьте себе что-то в духе сделай Х, потом Y, иначе Z, где каждое действие выполняется неопределенное количество времени, да еще требует какие-то сторонние результаты. Звучит просто? Когда встретитесь — увидите столько подводных камней.
Про задачи в стиле "обработать много гб данных, быстро и памяти много не требовать" говорить не хочется даже.
Токарь не имеет дел с задачами, требования которой противоречат друг другу, у программиста такое может быть, как раз из-за того, что отношение как к какому-то быдлу, мол можно за 30-70к нанять джуна и он быстро задачу решит нам. А потом во всем оказываются виноваты конечно же программисты. ПМ непогрешим, а тех дир вообще святой.
Токарь не имеет дел с задачами, требования которой противоречат друг другу
Если вы про нормальное производство (а не артель «Иванов и собутыльники»), и достаточно сложное изделие (а не про какую-нить втулку или шайбу), то у токаря есть технологическая карта на изделие, разработанная технологом, проверенная (не всегда, шутка про огурцы все так же актуальна;)) и подписанная кучей людей, и которая гарантирует результат (если ее не нарушать).
И вот технолог — это и есть тот человек, который получает/выясняет требования к изделию, убирает противоречия (в частности, с физическим миром и его законами), и планирует, как собственно это изделие должно быть сделано. И чтобы стать технологом, стажа токаря категорически недостаточно — нужно оттрубить несколько лет института (со всеми мозгодробительными предметами типа сопромата и материаловедения), а потом еще неопределенное количество лет — получать практический опыт (желательно в команде с уже состоявшимся технологом).
Возвращаясь в уютный мир ИТ офисов и сложных информационных систем, аналог технолога здесь — это ИТ архитектор. Он может не быть програмистом/админом/… (скорее даже «не должен быть», хотя технический бекграунд и желателен), но именно он занимается превращением набора хотелок в архитектуру («технологическую карту»), которую в дальнейшем програмисты («токари») превращают в конечный продукт («изделие»). К сожалению, в наших институтах ИТ архитекторов не учат (во всяком случае, мне об этом ничего не известно), так что приходится догоняться самостоятельно, ну и практический опыт в команде с другим архитектором — must have.
Если вы про нормальное производство (а не артель «Иванов и собутыльники»), и достаточно сложное изделие (а не про какую-нить втулку или шайбу), то у токаря есть технологическая карта на изделие, разработанная технологом, проверенная (не всегда, шутка про огурцы все так же актуальна;)) и подписанная кучей людей, и которая гарантирует результат (если ее не нарушать).
И вот технолог — это и есть тот человек, который получает/выясняет требования к изделию, убирает противоречия (в частности, с физическим миром и его законами), и планирует, как собственно это изделие должно быть сделано. И чтобы стать технологом, стажа токаря категорически недостаточно — нужно оттрубить несколько лет института (со всеми мозгодробительными предметами типа сопромата и материаловедения), а потом еще неопределенное количество лет — получать практический опыт (желательно в команде с уже состоявшимся технологом).
Технолог — это не токарь, и разница слишком огромна, примерно как между кандидатом наук и доктором наук.
К сожалению, в наших институтах ИТ архитекторов не учат (во всяком случае, мне об этом ничего не известно), так что приходится догоняться самостоятельно
Потому что вариативность того, с чем новоиспеченный ИТ архитектор может столкнуться так велика, что к тому времени, как он обучится — будет никому не нужен. В случае же отсутствия опыта работы "в поле" он вообще будет нести чушь и ахинею. Требовать невозможное от конкретных, уже существующих технических решений. Любой технолог по крайне мере в теории на 100% осознает как и что будет делать токарь Вася. И он может с гарантией сказать на что тот или иной токарь будет способен — от того и идут категории. Процесс унифицирован и стандартизирован до нельзя.
И как раз отсутствие понимания того, как работает программист у любого архитектора и приводит к появлению новых "чрезвычайно эффективных фреймворков и стандартов". Всякими js фреймворками уже весь инет забит, и выходят они каждый день — подаются как убийца предшественника и вообще единственный тру-фреймворк.
Подход, при котором вы полностью доверяете кодерам продукт на разработку почти всегда заканчивается бойлерплейтом и гавнокодом — что напрямую говорит об отсутствии квалификации. Если ваши архитекторы в упор не видят с чем исполнители будут иметь дело — то продукт будет завален костыльными решениями, гавнокодом другого рода — гавноархитектурой. И если проблему с отдельным кодером решить можно, то с архитектором — слишком дорого. Потому ОС Windows NT как технология — отличная штука, но даже с не особо хорошей реализацией — она реально хороша (говорю как заядлый линуксоид). А какая-нибудь поделка сделанная на коленке для полноценной демонстрации идеи, с самым идеальным кодом — кусок ненужного гуано — потому что архитектура в 100% не продумывается. Хотя за обе программы платят деньги.
И последнее, аналогом технологической карты для кодеров, которую делали бы ИТ архитекторы — это и будет сам код или блок-схема. Но в том-то и дело, архитектор не пишет кода, он программирует программирование других людей в заданном направлении. А вот технолог полностью определяет всю цепочку действий, которые осуществит конкретный токарь.
Возвращаясь в уютный мир ИТ офисов и сложных информационных систем, аналог технолога здесь — это ИТ архитектор. Он может не быть програмистом/админом/… (скорее даже «не должен быть», хотя технический бекграунд и желателен), но именно он занимается превращением набора хотелок в архитектуру («технологическую карту»), которую в дальнейшем програмисты («токари») превращают в конечный продукт («изделие»)
Вы, простите, с дуба рухнули? Как возможно спроектировать то, о чем ты не знаешь, у Solution Architect или ИТ архитектора должен быть очень большой бэкграунд, знание нескольких технологий структур на них, опыт их эксплуатации от и до. Собственно разработкой и как надо управляет архитектор, а сроками материальным обеспечением и т.д. менеджерские позиции (это если по фэн-шую).
И инженеров-технологов отправляют на стажировки на производства токарями, слесарями и т.д. (ну по-крайней мере отправляли, что сейчас я чёрт знает).
Так что не несите ерунды.
Архитектор это очень сильный и скилловый разработчик с + опытом в администрировании, эксплуатации, сбору аналитики и управлению командой.
Во первых, почему вообще эти должности должны сменять разработчика? Процессы за которые он отвечает — низкоуровневые, аналитик и ПМ — высокоуровневые. Вы еще ПМа пол попросите вымыть в офисе. А откажется — так значит он не годен ни на что, уборщица — вот кто ключевой работник на самом деле.
Кстати, не думали, почему у перечисленных вами зарплаты выше чем у кодеров (ну кроме QA), а зачастую в разы выше?
То что любой разработчик успешно сможет их заменить, явно абсурдна. Те кто может, давно уже и так там, но как видно, это явно не все :)
Во вторых, ваша аналогия с заводом заведомом демагогична. Технолог, главный инженер или исполнительный директор на заводе ни в коем роде не обязаны иметь возможность заменить слесаря или там токаря. В конце концов, они могут банально физической силой, достаточной для этого не выйти, или вообще просто не любить руки замарать. То есть аналогия с разработкой прямая, а вовсе не обратная, как вы стремитесь представить
Про ИТ-бизнес и не только