チームの人を活かすということ - My Life After MIT Sloan
最近、TAをやってる授業の中間発表が近くなってきたため、学生のチームと面談をやることが増えてきた。 私が直接頼まれて相談に乗ることもあるが、大体は先生とチームとの面談に私も参加する、という感じ。 先生がチームをどう指導するかを見てると勉強になる。 昨日は、先生の指導を見ていて、ひとつはっとさせられたことがあったので、メモっておく。 起業や企業経営にも役に立つ話だと思う。 昨日面会したチームの中にひとつだけ、明らかに問題を抱えているチームがあった。 軍隊出身の真面目なアメリカ人がリーダーっぽくやってるチームなのだが、 チームメンバーの一人が忙しいことを理由にほとんどミーティングにも参加せず、貢献もしないのだという。 更に、授業で与えられた課題を元にテーマを設定したが、非常に難しく、難航しているという。 その軍隊出身のリーダーは、メンバーがちゃんと参加しないことでチームの風紀が乱れており、 そ
SW開発で火を噴くパターン - プログラマの思索
【1】SW開発ではいつも結合テスト以降で火を噴く。 設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。 例えば、下記のような問題がいつでもどこでも噴出するのではないか。 設計書には、複数の画面遷移による業務フローが考慮されていなかった。 業務のインターフェイスがシステムとして整合性が取れていなかった。 シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。 つまり、設計漏れ。 実際に結合テスト環境で動かそうとすると、そもそも動かない。 実は、DB環境にViewやプロシージャがもれていた。 あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。 モジュールをビルドして、Webサーバーを再起動する作業が手順化されて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 凡才の集団は孤高の天才に勝る―「グループ・ジーニアス」が生み出すものすごいアイデア: キース・ソーヤー (著), 金子宣子 (翻訳): 本
