概要 †
- 技術マネジメント、経営マネジメントの方法
- 苦手なもので戦ってはいけないし戦わせてもいけない
有能さ †
- 他人のリスクを把握すること。他人を尊敬すること。
- 穴だらけの知識の中でも、チームで価値を生み出せること
- 穴を高速に必要な部分だけ埋める、穴を避けて語る、穴を高速に埋められる人にお願いする人脈
- 部下のモチベーションを上げること
- 能力だけでなく、自分がいるコミュニティに貢献すること。
- オーバヘッド
- ルール決めるとコストになるので，各自の裁量でやってください．
- 技術的難度と開発コストを見積もれることはエキスパートの条件
下位ページ †
目的意識 †
- 組織は目的を共有する人の集まりである。
- 必要な目的設定を見誤らないこと
- 課題解決への熱意のなさに「いらっ」とくる
- 「人工知能」という単語を無邪気に使うかどうかが、信用できる人かどうかの分かれ目みたいなところある。
得意分野 †
モラル †
- セクハラめいたことをスタッフや学生がやりだしたら、即座に100%否定して不快感を示す
- 大人の対応しましょうねとか被害者に言うというは一番ダメ
技術維持 †
- 技術向上し続けることが大事
- 上司「刃を研ぐのは業務外だから時間外にやれ」
- 経理「砥石を買う予算なんてありません、自費で用意してください」
- 監査「会社の備品を私物で整備することは認めない」
- そうじゃないとウェブマンみたいに買い叩かれることになる
- どれくらいのバランスがよいのか？
部下の指導 †
- 「言いたいこと言うだけの無責任なアドバイス」はダメ
- 自分の意思だけ伝えて、「ほらアドバイスしたのにー」だけは言ってはいかんのだよな。
システムは自動的に回らなければならない †
- 人間の努力や注意力に依存したシステムは必ず破綻する
- 人間がミスしないことを前提にした運用は必ず破綻する
部下への仕事の振り方 †
- 「まずスケッチを描きます、つぎに奴隷をみつけます、そしてうなぎを食べさせ、レッドブルを与えます」
納期 †
- エンジニアは納期を守らない
- 正確な見積ができない
- 新しい技術が必要なことがある
- もちろん古い技術を使えば早く実装できるが、新しい技術を取り入れていかないと、時代に取り残される
- 新しい技術を取り入れないとエンジニアのモチベーションが保てない
- 見積もり段階で決まっていない仕様がある（60-160%の誤差がある→3倍の時間で見積もるということになる）
- 正確に見積もるために
- 見積に失敗したら
- めちゃめちゃ強い火消し屋を投入する
- それが無理なら、開発範囲・費用・期間・品質のどれかを犠牲にする
- 犠牲にしないと品質が落ちるので、次の開発でバッファになる
- 人数を追加すると絶対遅れる
人員配置 †
- 技術に関してスペシャリストを集める際にバックグラウンドが近い人が最低2人は組めた方がいい。
- reviewがお互いにできる
- discussionが深くならないとそもそも働いてる側は楽しくない
- 知的好奇心を満たせるパートナーがいないと辛い
チームワーク †
- 他人をリスペクトする
- デザイナーがいるなら、どうすべきと研究者コミュニティの議論をする必要はないのだ！
- ディスらない。直接言う。
- 美しくないコードをuncodeとかクソースなどと呼ぶ人もいる
- これらの言葉は開発者を傷つけるので、最近アプレッソでは、あまり美しくないコードを「ひよコード」、美しくない箇所は「ここがピヨピヨしてる」と表現するようにしています。未熟だけど伸び代はあることを意味しています。
- 程度の副詞の程度に注意する。
- マネジメントがうまく言っていない場合、きちんと口に出す。きちんと皆で仕事をする。
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
