1) вы 10 лет разрабатываете софт, а разработать по сути тот же софт тока основанный на людях вы не можете. Вам не кажется что вы себя обманываете? — разработка софта и принципа работы компании одно и тоже по сути, тулзы разные а идеи и принципы все теже. Все в нашем мире можно описать математически, так почему же у вас как у профессионала изменение обьекта влияния вызывает страх?
Я бы лично взялся управлять компанией. во первых потому что не хочу сидеть и тупить а хочу что то менять к лучшему, во вторых это чудесная практика, в третьих у меня куча идей на этот счет( со временем все больше из них подтверждаются практически).
Это мое мнение, насчет доказательств не знаю что вам сказать кроме встречного вопроса, а у вас есть доказательство что текущая идиология эффективнее?
2) Чем больше вы откладываете на завтра — тем больше завтра рубанет вас по голове. Есть проблема — решение не должно откладыватся.
Малоэффективный сотрудник это не сотрудник с низкой квалификацией а сотрудник который не хочет двигатся и тупо отсиживает.
3) Ко мне приходил директор и уже спрашивал, и сейчас я получаю столько сколько просил, и чувствую себя в принципе комфортно.
4) Группа людей вещь такая что рано или поздно там появится лидер. Но лидер который выборол право им быть и управленец которого назначили это очень большая разница. Я бы лучше сидел в карцере чем пошел бы под командования капитана который пороха не нюхал. Зато я доверю свою жизнь человеку который прошел 5 горячих точек и провел свой взвод без потерь. Иерархия же заставляет вручать свою жизнь вв руки штабных крыс.
5) Везде одинаково, все всегда чего то хотят, будь то клиенты или поставщики, или юзеры игр пофиг. Все хотят. Среди этого хотения есть правельные вещи а есть неправельные. Никогда не нужно делать то что хочет клиент, но всегда нужно ответить клиенту почему и сделать это адекватно и поблагодарить за его совет. Это 100% профит доказанный моей не короткой практикой. Суть в том что 1000 неверных идей может родить у вас в голове 1 верную, но без этой тысячи этого бы не произошло.
Идти на рынок ради наживи неправельно, ибо вы становите зависимы, а раз зависимы значит слабы. Нужно развивать продукт так что бы рынок сам просил вас туда прийти. Звучит как максимализм, но это так. Делай вещи хорошо и продавать их будет легче.
Разработчики это люди, а не мутанты какието. Меня всегда удивляет что до сих пор разработчиков видят как какихто бородатых уродово. В реальности же разработчики куда как общительней и интересней чем всякие там манагеры и жопосиды. Все девы которых я знаю постоянно путешествуют, общаются с тучей новых людей, участвуют в разных конкурсах и проектах. Одни играют в группах, драгие занимаются экстримом, третьи пишут книги и т.п. Разработчики это те люди у которых хорошо фурычит мозг(но при этом это не гении) а с умными людьми всегда есть о чем поговорить. И поверте клиенту куда интересней и приятне общатся с умным человеком своего уровня чем с тупым быдляком который расфуфырившысь пытается впихнуть ему насильно продукт. Прошло то время когда можно было тупо парить, сейчас клиенты стали куда умнее и такой мето в лоб уже не катит.
6) Конечно бывают, проблема только в процентном соотношении хороших и плохих. Знаете если 98 из 100 выпущенных деталей двигателя для мотоцикла разлетаются в хлам, а те 2 дают выхлоп +2хСкорости я никогда не поставлю их на свой байк, потому как это моя жизнь и так тупо рисковать надеясь на то что я найду то что мне надо я не буду.
Платить нужно столько сколько человек зарабатывает, никто не будет зарабатывать компании миллионы а получать с этого 1к уе бонуса. А я видел как наебывали так людей ставя им 5% от заработка а когда те приносили клиента и 100млн давали им не 5% а копейки. Иерархическая структура хочет что бы люди вкалывали за копейки… проблема только в том то за копейки вкалывают идиоты. И тут выбор или быть рабовладельцем и довольствоватся малым, или делить прибыли по чеснаку но захватывая мир. Второе всем кажется страшным только потому что в большинства головах сидит страх потери контроля, который по факту мнимый ибо иерархическая система не дает кантроля это не более чем фикция. Компанию можно сравнить со страной и гражданами. Практика развития общества показала что люди под контролем и запретами живут, работают, и чувствуют себя намного хуже, чем в странах с широкими возможностями. Многомиллиардное население мира уже доказало, что что бы достичь гармонии нужно не ставить людям палки в колеса. Так почему же в малюсиньких компаниях(по сравнению планетой) до сих пор живет уклад древней Японии?? — да только потому что толпа менеджером и управленцев которые по сути ничего не умеют должни питаться, и так как их влияние в компании намного сильнее то они в один голос кричат что система без явного управления обречена… они просто бояться потерять работу, ибо система на результат сразу покажет что они из себя представляют.
Есть много компаний с сопоставивым кол-вом сотрудников как у Майкрософт и куда более качественным техпроцессом, да даже тот же гугл. Я обащлся как с теми так и с теми… и работать в мелкософте я не хочу, ибо это 100% рабство напоминающее мне работу в банке. Да это мое личное мнение.
Дружелюбные практики из стартапов рождают новые технологии и принципы построения компаний. Фейсбук к примеру тоже по вашим словам небольшой стартапчик, но тем не менее он может смело конкурировать с мелкософтом. Так что сдесь вопрос не кол-ва сотрудников а умелого управления компанией и процессом.
Насчет 80/20 дам простой совет. Ваша команда/компания это как взвод спецназа и ваша цель захватить место на рынке. Как и в спецназе сдесб работает простой закон — промашка одного стоит жизни многих. Посему видя что человек не справляется или не хочет идти дальше с ним лучше прощатся, ибо ваши цели и цели ваших работников должны пересекаться. Иначе это всеравно что дружить с тем с кем у вас нет ничего общего, ну или выйти замуж за мужика(с учетом того что вы оба гетеро). Всегда что бы понять ситуацию нужно ее проецировать на другие сферы жизни общества, тогда все становится куда понятней и однозначней.
А давайте будем смотреть на практику и реалии а не на теорию.
1) Майкрософт вообще имеет одну из самых ужасных идеологий управления.
2) Если человек не нужен то зачем он? вы говорите баласт, а зачем компании баласт. Моя практика показывает что лучше рассаться с человеком сразу и мирно, чем потом и с криками. Если 80% работают на 20% увольте их нафиг и зп разделите среди оставшихся и новеньких, это даст куда больший выхлоп чем таскание мертвого тела.
3) Наверно потому что у все ЗП ниже той суммы которая нужна для нормальной жизни. Вот у меня ЗП выше среднего, но при этом я бы не сказал что она настолько велика что решает все мои финансовые проблемы.
4) Говорится о возможности, а не обязанности. Хочешь принимай решения, хочешь советуйся с кем то и принимайте вместе. Суть в том что у тебя есть выбор чем заниматься, а не ка в армии, сказали копать -копаешь, сказали не копать — не копаешь. + есть люди которые к чему то стремятся и именно такие люди имееют особое значение для компании и компания должна ориентироватся на них а не на увольней.
5) Удовлетворение клиента очень важная вещь, особенно для малых компаний, это позволяет вам быстро и высоко взлететь с малыми затратами.
Да и странно когда компания творит непонятно что в то время как клиенты приносящие ей деньги не довольны. К чему стратегии и развитие, если недовольные клиенты перейдут к конкурентам?
6) Менеджеры и босы являются поддержкой наверно 2 случаях из 100 если не меньше. В остальном это толстые боровы которые абсолютно безсполезны, и даже вредят компании ибо единственная их цель это напиздить как можно больше бабла себе. В УкрСибБанке к примеру распил проектов среди начальниками обычное дело. Из серии вот мы купили карту за фиг знает скока денег, и начальники такие сразу бац, кто машину новую купил, кто виллу за городом… — Такое нужно присекать. И модель управления когда сам ты ничего не зделаешь сдесь помогает.
На личной практике и сделанных на этом выводах + практика других компаний которые рискнули выйти из общего течения.
Если честно то еще не встречал ни одну компанию которая перешла бы на подобную идиологю развития и провалилась бы. Может конечно такие и есть, но я о них не слышал.
На тему ЗП иерархия тоже вызывает большие проблемы, так как зачастую за удачно сданный проект команда его делающая получает допустим Х бонуса на каждого, в то время как руководитель отдела где они работают получает 50Х бонуса, хотя при это он вообще не участвовал в проекте. Такая политика вызывает то что как и говорилось в статье, люди работают не на интересы компании и в следствии свои собственные, а исключительно на интересы начальника. Если кто работал в банках тот поймет. Я имел практику в банке более года и могу точно сказать что 90% всех руководителей и менеджеров можно смело уволнять нафиг, ибо они кроме росказней как кому стоит работать они ничего не делают. И так впринципе в каждой компании.
Собственно появляется вопрос а нафига тогда это все? — и вот как раз отказ от иерархии это ответ. Личная ответственность каждого и ориентировка на результат. Поверте человек может сделать куда большее когда дать ему возможность принимать участвие в развитии компании и дать вохможность получать с этого деньги(именно за свои успехи, а не за отслужку лет и должность).
Прочитал статью и снова поддержу автора. Собственно и сам давно об этом говорю и даже написал пару статей на эту тему.
Думаю если они совместят свою идеологию еще и идиологие стека бонусов за улучшение компании, то еще более увеличат прибыль и качество своих услуг.
anjensan, ответ был не вам а syschel, просто вложенность закончилась)
SQL благо ибо не требует изучения лишней фиговины. Это можно сравнить с шаблонизаторами для пыхи к примеру. Вот зачем человеку учить Smarty что бы писать шаблоны, не лучше ли сразу выучить пыху? Нативные шаблонизаторы работают куда быстрее, проще, больше функционала.
SQL тоже нада портировать, но логичнее портировать SQL делая так что софт юзает максимум возможностей системы, нежели портировать с ОРМ урезать себя в возможностях и как следствие в скорости работы и качеству софта.
Потому как к примеру есть вообще другие БД, ннапример Mongo, Couchbase, как на них портировать? А если нельзя то в чем прок? Под одну БД портируем ОРМ а под другую пишем нативные запросы? — это бредово.
Вообщем за всю свою жизнь я не увидел плюсов в ОРМ, разве что для строительства бложков с нагрузкой в 100 уников/сутки
Я вам открою секрет как человек переносивший с MySQL на PostgreSQL проекты. Они может визуально и похожи, но в реальности очень разные. И то что работает на мускуле не всегда работает на Postgre, а то что есть на Postgre нету на мускуле. Вот к примеру на мускуле нет геоиндекса, как его будете переносить? — А никак, ибо невозможно. Таких нюансов сотни. Да конечно бложик перенесете без проблем, а вот HL проект с вылизанными запросами под минимизацию нагрузки никогда в жизни. Посему забудте о портировании.
Во вторых обобщенное никогда не работает лучше специализированного.
Программист баз данных есть только в Ораклах, ибо там реально програмят под БД. Остальные программят в коде а БД оптимизируют под скорость.
я обычно в проектах юзал twisted, tornado(дописанный) потом перешел на gevent. Правда скрещивать это с синхронным фреймом не очень гуд, появляется много нюансов. Куда проще написать свой микрофрейм и юзать его.
Написать можно, вопрос во что это превратится. Проблема в том что я могу взять ОРМ и составить логически такой запрос как у вас выше, но я понятия не буду иметь в какой запрос SQL он в реальности трансформируется, а без этого я не могу говорить о его эффективности, что не допустимо в сложных проектах. А если лезть в дебри ОРМ изучать принцип построения то вопрос тогда зачем его использовать.
Мой лично принцип говорит если что то можно сделать без библиотеки не сильно перерабатывая, то нада делать без нее. Ибо понимание того как работает твой код крайне важно при нагрузках. А когда 90% кода сторонние библиотеки которые никто не знает как работаю то считай проект на самотеке и зависит не от разработчиков, а от разработчиков сторонних библиотек. Для тех людей кто умеет считать риски думаю понятно куда заводят такие вещи.
используйте многоуровневый кеш и подумайте над денормализацией БД. Я сейас стараюсь перевести весь софт к работе с локальным кешем вместо БД. Тоесть в разрезе сессии человек не обращается к бд а работает с локальным кешем, потом он сносится в базу. Это существенно снижает нагрузку на БД и ускоряет работу. Правда к сайту это не подойдет.
Для сайтов нужно делать систему виджетов со своей локальной обработкой и подгрузкой асинхронно. Тоесть контент генерится странице все осталньое сторонние виджеты. Это позволяет делать качественное кеширование и не задормаживать загрузку основного контента.
С это язык а не серебренная пуля, и считать что на нем все круче работает это ошибка. Сравните например С и Erlang по работе с сетью и вы удивитесь тому как С проигрывает(разумеется если вы не пишите на нем второй Erlang со шлюхами и блекджеком).
Я лишь говорю о том что в HL выбор технологий исходит не из того что нашней программистам, а из того что разгружает систему. И если к примеру переписание какогото модуля на Си реально решит проблему, то так и стоит сделать.
Важно понимать затраты своего приложения при оценке. Если вы можете потратить 3к уе и переписать код на Си который секономит вам 5 серваков, то это хороший вариант и очень дешевый, если же написание занимает 100к уе, в то время как нада купить 20 серваков, то это плохой вариант. Это конечно обобщенно все.
ORM же плюха чисто для программеров и не более. Причем в реальных, сложных проектах она только мешает. Попытка обьединеть бизнес с кодом ошибочна в своем понимании. Ибо это всеравно что сказать мы возьмем куб и перенесем его в 5 мерное пространство где он будет выгляди абсолютно так же. По факту перевод данных из области в области, это отображение, причем не всегда биективное.
Странное вы сравнение приводите. Вы пришли когда код писали юзеры(тоесть что бы они не написали это Г), а потом вы написали код н ОРМ и все ок. Разумеется будет ок, вы ведь программист, и это заслуга не ОРМ а того что вы пишите норм код. НО, если бы вы написали код вне ОРМ думаю было бы быстрее.
В HL экономят не время разработчика а ресурсы. Тем более я понятия октровенно не имею где вы так много экономите времени разработчика при написании запросов через ORM.
Я бы лично взялся управлять компанией. во первых потому что не хочу сидеть и тупить а хочу что то менять к лучшему, во вторых это чудесная практика, в третьих у меня куча идей на этот счет( со временем все больше из них подтверждаются практически).
Это мое мнение, насчет доказательств не знаю что вам сказать кроме встречного вопроса, а у вас есть доказательство что текущая идиология эффективнее?
2) Чем больше вы откладываете на завтра — тем больше завтра рубанет вас по голове. Есть проблема — решение не должно откладыватся.
Малоэффективный сотрудник это не сотрудник с низкой квалификацией а сотрудник который не хочет двигатся и тупо отсиживает.
3) Ко мне приходил директор и уже спрашивал, и сейчас я получаю столько сколько просил, и чувствую себя в принципе комфортно.
4) Группа людей вещь такая что рано или поздно там появится лидер. Но лидер который выборол право им быть и управленец которого назначили это очень большая разница. Я бы лучше сидел в карцере чем пошел бы под командования капитана который пороха не нюхал. Зато я доверю свою жизнь человеку который прошел 5 горячих точек и провел свой взвод без потерь. Иерархия же заставляет вручать свою жизнь вв руки штабных крыс.
5) Везде одинаково, все всегда чего то хотят, будь то клиенты или поставщики, или юзеры игр пофиг. Все хотят. Среди этого хотения есть правельные вещи а есть неправельные. Никогда не нужно делать то что хочет клиент, но всегда нужно ответить клиенту почему и сделать это адекватно и поблагодарить за его совет. Это 100% профит доказанный моей не короткой практикой. Суть в том что 1000 неверных идей может родить у вас в голове 1 верную, но без этой тысячи этого бы не произошло.
Идти на рынок ради наживи неправельно, ибо вы становите зависимы, а раз зависимы значит слабы. Нужно развивать продукт так что бы рынок сам просил вас туда прийти. Звучит как максимализм, но это так. Делай вещи хорошо и продавать их будет легче.
Разработчики это люди, а не мутанты какието. Меня всегда удивляет что до сих пор разработчиков видят как какихто бородатых уродово. В реальности же разработчики куда как общительней и интересней чем всякие там манагеры и жопосиды. Все девы которых я знаю постоянно путешествуют, общаются с тучей новых людей, участвуют в разных конкурсах и проектах. Одни играют в группах, драгие занимаются экстримом, третьи пишут книги и т.п. Разработчики это те люди у которых хорошо фурычит мозг(но при этом это не гении) а с умными людьми всегда есть о чем поговорить. И поверте клиенту куда интересней и приятне общатся с умным человеком своего уровня чем с тупым быдляком который расфуфырившысь пытается впихнуть ему насильно продукт. Прошло то время когда можно было тупо парить, сейчас клиенты стали куда умнее и такой мето в лоб уже не катит.
6) Конечно бывают, проблема только в процентном соотношении хороших и плохих. Знаете если 98 из 100 выпущенных деталей двигателя для мотоцикла разлетаются в хлам, а те 2 дают выхлоп +2хСкорости я никогда не поставлю их на свой байк, потому как это моя жизнь и так тупо рисковать надеясь на то что я найду то что мне надо я не буду.
Есть много компаний с сопоставивым кол-вом сотрудников как у Майкрософт и куда более качественным техпроцессом, да даже тот же гугл. Я обащлся как с теми так и с теми… и работать в мелкософте я не хочу, ибо это 100% рабство напоминающее мне работу в банке. Да это мое личное мнение.
Дружелюбные практики из стартапов рождают новые технологии и принципы построения компаний. Фейсбук к примеру тоже по вашим словам небольшой стартапчик, но тем не менее он может смело конкурировать с мелкософтом. Так что сдесь вопрос не кол-ва сотрудников а умелого управления компанией и процессом.
Насчет 80/20 дам простой совет. Ваша команда/компания это как взвод спецназа и ваша цель захватить место на рынке. Как и в спецназе сдесб работает простой закон — промашка одного стоит жизни многих. Посему видя что человек не справляется или не хочет идти дальше с ним лучше прощатся, ибо ваши цели и цели ваших работников должны пересекаться. Иначе это всеравно что дружить с тем с кем у вас нет ничего общего, ну или выйти замуж за мужика(с учетом того что вы оба гетеро). Всегда что бы понять ситуацию нужно ее проецировать на другие сферы жизни общества, тогда все становится куда понятней и однозначней.
Каждый должен получать то на что заслуживает.
1) Майкрософт вообще имеет одну из самых ужасных идеологий управления.
2) Если человек не нужен то зачем он? вы говорите баласт, а зачем компании баласт. Моя практика показывает что лучше рассаться с человеком сразу и мирно, чем потом и с криками. Если 80% работают на 20% увольте их нафиг и зп разделите среди оставшихся и новеньких, это даст куда больший выхлоп чем таскание мертвого тела.
3) Наверно потому что у все ЗП ниже той суммы которая нужна для нормальной жизни. Вот у меня ЗП выше среднего, но при этом я бы не сказал что она настолько велика что решает все мои финансовые проблемы.
4) Говорится о возможности, а не обязанности. Хочешь принимай решения, хочешь советуйся с кем то и принимайте вместе. Суть в том что у тебя есть выбор чем заниматься, а не ка в армии, сказали копать -копаешь, сказали не копать — не копаешь. + есть люди которые к чему то стремятся и именно такие люди имееют особое значение для компании и компания должна ориентироватся на них а не на увольней.
5) Удовлетворение клиента очень важная вещь, особенно для малых компаний, это позволяет вам быстро и высоко взлететь с малыми затратами.
Да и странно когда компания творит непонятно что в то время как клиенты приносящие ей деньги не довольны. К чему стратегии и развитие, если недовольные клиенты перейдут к конкурентам?
6) Менеджеры и босы являются поддержкой наверно 2 случаях из 100 если не меньше. В остальном это толстые боровы которые абсолютно безсполезны, и даже вредят компании ибо единственная их цель это напиздить как можно больше бабла себе. В УкрСибБанке к примеру распил проектов среди начальниками обычное дело. Из серии вот мы купили карту за фиг знает скока денег, и начальники такие сразу бац, кто машину новую купил, кто виллу за городом… — Такое нужно присекать. И модель управления когда сам ты ничего не зделаешь сдесь помогает.
Если честно то еще не встречал ни одну компанию которая перешла бы на подобную идиологю развития и провалилась бы. Может конечно такие и есть, но я о них не слышал.
На тему ЗП иерархия тоже вызывает большие проблемы, так как зачастую за удачно сданный проект команда его делающая получает допустим Х бонуса на каждого, в то время как руководитель отдела где они работают получает 50Х бонуса, хотя при это он вообще не участвовал в проекте. Такая политика вызывает то что как и говорилось в статье, люди работают не на интересы компании и в следствии свои собственные, а исключительно на интересы начальника. Если кто работал в банках тот поймет. Я имел практику в банке более года и могу точно сказать что 90% всех руководителей и менеджеров можно смело уволнять нафиг, ибо они кроме росказней как кому стоит работать они ничего не делают. И так впринципе в каждой компании.
Собственно появляется вопрос а нафига тогда это все? — и вот как раз отказ от иерархии это ответ. Личная ответственность каждого и ориентировка на результат. Поверте человек может сделать куда большее когда дать ему возможность принимать участвие в развитии компании и дать вохможность получать с этого деньги(именно за свои успехи, а не за отслужку лет и должность).
Думаю если они совместят свою идеологию еще и идиологие стека бонусов за улучшение компании, то еще более увеличат прибыль и качество своих услуг.
А терь пойду почитаю)
SQL благо ибо не требует изучения лишней фиговины. Это можно сравнить с шаблонизаторами для пыхи к примеру. Вот зачем человеку учить Smarty что бы писать шаблоны, не лучше ли сразу выучить пыху? Нативные шаблонизаторы работают куда быстрее, проще, больше функционала.
SQL тоже нада портировать, но логичнее портировать SQL делая так что софт юзает максимум возможностей системы, нежели портировать с ОРМ урезать себя в возможностях и как следствие в скорости работы и качеству софта.
Потому как к примеру есть вообще другие БД, ннапример Mongo, Couchbase, как на них портировать? А если нельзя то в чем прок? Под одну БД портируем ОРМ а под другую пишем нативные запросы? — это бредово.
Вообщем за всю свою жизнь я не увидел плюсов в ОРМ, разве что для строительства бложков с нагрузкой в 100 уников/сутки
Во вторых обобщенное никогда не работает лучше специализированного.
Программист баз данных есть только в Ораклах, ибо там реально програмят под БД. Остальные программят в коде а БД оптимизируют под скорость.
Мой лично принцип говорит если что то можно сделать без библиотеки не сильно перерабатывая, то нада делать без нее. Ибо понимание того как работает твой код крайне важно при нагрузках. А когда 90% кода сторонние библиотеки которые никто не знает как работаю то считай проект на самотеке и зависит не от разработчиков, а от разработчиков сторонних библиотек. Для тех людей кто умеет считать риски думаю понятно куда заводят такие вещи.
Вообщем метод KISS еще ни разу меня не подводил.
Для сайтов нужно делать систему виджетов со своей локальной обработкой и подгрузкой асинхронно. Тоесть контент генерится странице все осталньое сторонние виджеты. Это позволяет делать качественное кеширование и не задормаживать загрузку основного контента.
А чем отличается плохое ОРМ от хорошего?
И что такое заточенное ОРМ? это типа вызов метода в котором внутри уже прописан правельный SQL запрос?
Я лишь говорю о том что в HL выбор технологий исходит не из того что нашней программистам, а из того что разгружает систему. И если к примеру переписание какогото модуля на Си реально решит проблему, то так и стоит сделать.
Важно понимать затраты своего приложения при оценке. Если вы можете потратить 3к уе и переписать код на Си который секономит вам 5 серваков, то это хороший вариант и очень дешевый, если же написание занимает 100к уе, в то время как нада купить 20 серваков, то это плохой вариант. Это конечно обобщенно все.
ORM же плюха чисто для программеров и не более. Причем в реальных, сложных проектах она только мешает. Попытка обьединеть бизнес с кодом ошибочна в своем понимании. Ибо это всеравно что сказать мы возьмем куб и перенесем его в 5 мерное пространство где он будет выгляди абсолютно так же. По факту перевод данных из области в области, это отображение, причем не всегда биективное.